Related Applications

[0001 ] This application claims the benefit of provisional patent application serial number 62/189,043, filed July 6, 2015, the disclosure of which is hereby incorporated herein by reference in its entirety.

Technical Field

[0002] The present disclosure relates to CatchUp Television (TV) services that allow end users to access media content for an extended period of time.

Background

[0003] To aid in the understanding of the subject matter disclosed herein, the following glossary of terms is presented:

[0004] Internet Television (ITV): services and programs that are delivered to client devices from a media server by using the architecture and networking methods of the Internet Protocol (IP) suite over a packet-switched network infrastructure, e.g. the Internet and broadband Internet access networks, instead of being delivered through traditional radio frequency broadcast, satellite signal, and Cable TV (CATV) formats. Also referred to as Internet Protocol Television (IPTV).

[0005] The content that is provided to the consumer via ITV can take a variety of forms, which vary from those where the consumer has no control over the timing or the content of the programming to those where the consumer has significant control of the timing and content of the programming. These include:

[0006] Linear TV: a television service where the viewer has to watch a scheduled TV program at the particular time it's offered, and on the particular channel it's presented on. Commercial Linear TV is typically characterized by advertisements embedded within and in between programs. Also referred to as scheduled content TV. [0007] Time Shift TV: a television service that allows the end user to pause, rewind, fast forward, or resume a linear TV program while it is being broadcast. Fast forward is possible up to the point in time when the recorded stream being played becomes identical to what is being broadcast live. The capture of time shift content is either done on the local client equipment (e.g., a Set Top Box (STB)) or in the network (e.g., a media server).

[0008] Video-on-Demand (VoD): a service which offers end-users the ability to browse a specific catalogue of pre-recorded content (e.g., TV shows, movies, and the like) and purchase or rent a specific content for consumption (e.g., viewing). The VoD Service Provider (SP) may impose a consumption window that limits the timeframe which content may be consumed. In other words, the VoD SP may limit access to paid content for a limited time such as 24 hours or several days.

[0009] Live2VoD: a service which offers end users the ability to browse a specific catalogue of pre-recorded content (e.g., TV shows, movies, or the like) and purchase or rent specific content for consumption (for viewing). The VoD SP may impose a consumption window that may limit the timeframe during which content may be consumed. In other words, the VoD SP may limit access to paid content for a limited time such as 24 hours or several days.

[0010] Subscription VoD (SVoD): a subscription service which offers end- users consumption rights (i.e., access rights) to a VoD catalogue of pre-recorded content. Typically for or a monthly subscription fee, an end-user has unlimited access to a VOD catalogue for a period of time. One example of an SVoD service is Netflix™.

[0011 ] A distinct but related technology involves the ability of a user to record or make personal copies of program content. These include:

[0012] Digital Video Recorder (DVR): a consumer electronics device or application software that records video in a digital format to a disk drive,

Universal Serial Bus (USB) flash drive, Secure Digital (SD) memory card, Solid State Drive (SSD), or other local or networked mass storage device. Sometimes referred to by the merchandising term Personal Video Recorder (PVR). TV programs can only be recorded by a DVR in real time while the programs are being broadcast. The recorded programs are stored in the DVR for a predetermined period of time or until a user designates the programs for deletion.

[0013] Cloud DVR: (also known as network DVR, or NDVR) digital video recording capabilities deployed from the cloud (i.e., a network of remote servers hosted on the Internet and used to store, manage, and process data in place of local servers or personal computers), whether the Pay TV Operator's network or a third party cloud service. This means that subscribers can record live content and shows (i.e., programs broadcast in real time) using storage in the operator's or third party provider's network, instead of on the hard drive in the subscriber's home DVR STB. These recorded shows can be watched anywhere, on any device, at any time.

• In the private-copy cloud DVR model, one copy of the requested TV program is stored in the network per subscriber, and each stored program is available only to the subscriber who made the recording request. If two subscribers want to record the same content, duplicate copies are made, making this model less cost-efficient than the shared-copy model.

• In a shared-copy cloud DVR deployment, a single copy of each recorded program is stored in the network and accessed by multiple subscribers.

The key advantage of shared-copy cloud DVR is efficiency: the service only has to ingest and store one copy of each recorded program.

Local regulations may affect how service providers can offer cloud DVR services to their subscribers. Many jurisdictions impose the private-copy cloud DVR model to adhere to regional copyright laws.

[0014] CatchUp TV: a television service offered by operators whereby scheduled content from a linear TV service is recorded on network (e.g., cloud) resources and then offered for end-user consumption after the program broadcast is complete or while the program is still being broadcast. CatchUp TV offerings usually groups programs with a common theme such as episodes from a series. The recorded programs are typically made available to a user for a predetermined period of time (e.g., seven days), after which they are

automatically designated for deletion.

[0015] In particular, CatchUp TV is a service by which all Linear TV programs, or some limited set of Linear TV programs, are recorded in the cloud by, e.g., the network operator. The recorded Linear TV programs for CatchUp TV (which are sometimes referred to herein as CatchUp TV programs) are stored for a limited amount of time (e.g., seven days) during which viewers (e.g., viewers that have subscribed to the CatchUp TV service) are enabled to watch the recorded Linear TV programs for CatchUp TV, e.g., according to their subscriptions. Problems with existing solutions

[0016] Television (TV) service providers offer content to viewers according to a variety of methods including free or paid subscription services. Examples of these services include Linear TV and Time Shift TV. TV content may be captured according to a variety of methods including use of DVR devices, cloud DVR services, VoD services, and CatchUp TV services.

[0017] Different storage methods can be used to maintain copies of media content for cloud based recording services. For example, a private copy is an individual redundant copy of a program stored for an individual whereas a shared copy is a single copy of a live broadcast that may be shared between end users.

[0018] In a private copy cloud based recording model, one copy of a requested TV program is stored in the network per subscriber that made a recording request, and each stored program is available only to the subscriber who made the recording request. In other words, media content is recorded for a requesting user and that recording is only made available to the requesting user. As such, multiple subscribers each recording the same broadcast program would result in multiple individual digital copies of the same program being recorded and stored for those subscribers, which requires significant capital and resource investments to store and manage the redundant copies of media content. Thus, if two subscribers want to record the same media content, duplicate copies of the media content are made, which makes this service less cost efficient than a shared copy model. [0019] In a shared copy cloud based recording deployment, a single copy of each recorded program is stored in the network and each single copy can be accessed by multiple subscribers. An advantage of shared copy cloud based recording deployment is efficiency because the service only has to receive, process, and store one copy of each recorded program on the network. Notably, CatchUp TV services use a shared copy deployment rather than a private copy deployment.

[0020] Figure 1 A (Prior art) illustrates an application of the so called "80/20 principle" to manage media content where 80% of streams are requested for 20% of the most popular media content, and Figure 1 B (Prior art) is a network diagram showing a tiered content delivery network topology. To achieve efficient resource utilization, typically a tiered content delivery network topology, such as that shown in Figure 1 B, is recommended for storage and distribution. A tiered topology allows for storing content centrally (e.g., at a central site) and moving it dynamically across media servers according to usage. Popular content can be placed in media servers at the edge of the network (e.g., Edge Site 1 through Edge Site N), so that multiple recipients have access to the same copy of the content that is stored locally. This reduces the traffic load on the network backbone, helping to provide capacity for more concurrent users. Following the 80/20 principle, the 20% most popular assets would be placed at edge sites of the network topology (e.g., closer to the end consumer). Placing popular assets at or near the edge of a tiered network provides the advantage that users will experience better streamed quality most of the time and the operators can reduce their costs by regulating network load efficiently as well as reducing latency and improving network Quality of Service (QoS).

[0021 ] However, North American operators and service providers are bound by Federal Communications Commission (FCC) and Canadian Radio-Television and Telecommunications Commission (CRTC) regulations, which mandate that NDVR content be stored as private copies for each subscriber. As a result, multiples of copies of the same content are pushed out to the media servers at the edge of the network. With thousands (if not millions) of redundant copies of private recorded programs, it becomes a challenge for operators to apply the 80/20 rule and to push freshly recorded content to the network edge sites.

Significant capital and resource investments are required to store and maintain all of these multiple copies of the same content.

[0022] These requirements, and the significant resources needed to satisfy these requirements, apply to technologies where content is recorded by the subscriber or operator for the subscriber's later consumption, such as NDVR and CatchUp TV, but do not apply to VoD, under the theory that VoD content was not recorded by or for a particular subscriber's use.

[0023] Typically, the offerings within a CatchUp TV service are treated as a VoD asset and not as a recording asset belonging to the subscriber. However, existing CatchUp TV services can only record a program in real time while the program is being broadcast. In other words, CatchUp TV services do not include media content that was not obtained from a live broadcast. Existing CatchUp TV services capture media content from a live broadcast irrespective of any interest in the media content expressed by any user. In other words, CatchUp TV services do not require a request to record a particular program. Notably, the offerings of media content made in accordance within a CatchUp TV service are treated as a VoD asset and not as a recording asset belonging to a subscriber. Thus, any media content made available via CatchUp TV services is not recorded for any particular user. As such, the end user cannot designate any media content for deletion in CatchUp TV services. Moreover, VoD providers typically do not provide local broadcast content.

[0024] Thus, there is a need for methods and systems that allow individual subscribers to have access to stored broadcast programs, including local broadcast content, in a manner that satisfies regulatory requirements while requiring fewer capital and financial resources.

Summary

[0025] The present disclosure provides systems, methods, and devices for improving, enhancing, and/or extending CatchUp Television (TV) services. In some embodiments, a method of operation of a server computer comprises maintaining Virtual Lockers (VLs) for subscribers. A VL is a data construct for storing information that identifies, for each subscriber, CatchUp TV program content available for viewing by the subscriber. Other types of information may be stored in the VL, including, but not limited to, subscriber information, subscription information, and information identifying other types of program content. The VLs include references to a subset of CatchUp TV program(s). The method further comprises retaining the subset of the CatchUp TV

program(s) according to an extended retention policy, and retaining the CatchUp TV program(s) other than the subset of the CatchUp TV program(s) according to a default CatchUp TV retention policy. Beneficially, the improved CatchUp TV services use individual copies of media content that are shared by individual end users instead of maintaining individual copies for each end users resulting in inefficient use of resources.

[0026] In some embodiments, the CatchUp TV programs comprise programs that are broadcast before receiving the request, programs currently being broadcast when the request is received, and/or programs to be broadcast after receiving the request.

[0027] In some embodiments, maintaining the VLs for subscribers comprises creating VLs for subscribers, receiving a request from a subscriber to add a reference to a VL associated with the subscriber, identifying CatchUp TV program(s) that match the request, adding the reference to the VL, and incrementing a counter value for each identified CatchUp TV program.

[0028] In some embodiments, maintaining the VLs for subscribers further comprises receiving a request from a subscriber to remove a reference from a VL associated with the subscriber, identifying CatchUp TV program(s) that match the reference, removing the reference from the VL, and decrementing a counter for each identified CatchUp TV program.

[0029] In some embodiments, the method of operation of a server computer further comprises determining whether a default retention period for a CatchUp TV program has expired. Upon determining that the default retention period has not expired, the server computer retains the CatchUp TV program in storage. Upon determining that the default retention period has expired, the server computer determines whether a counter value for references in VLs associated with the CatchUp TV program is equal to or less than a predetermined threshold. Upon determining that the counter value is equal to or less than the

predetermined threshold, the server computer designates the CatchUp TV program for deletion. Lastly, upon determining that the counter value is greater than the predetermined threshold, the server computer retains the CatchUp TV program in accordance with the extended retention policy.

[0030] In some embodiments, a method of operation of a server computer comprises creating VLs for CatchUp TV content, providing subscription based control of the CatchUp TV content, enabling subscribers of the CatchUp TV content to manage records contained in the VLs, and providing playout of programs referenced in the records contained in the VLs.

[0031 ] As used herein, the "playout" refers to the streaming or otherwise providing of stored broadcast or other content to an end user, usually for consumption by that end user (e.g., the end user watches the program).

[0032] Those skilled in the art will appreciate the scope of the present disclosure and realize additional aspects thereof after reading the following detailed description of the embodiments in association with the accompanying drawing figures.

Brief Description of the Drawings

[0033] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0034] Figure 1 A (prior art) illustrates an application of the so called "80/20 principle" to manage media content where 80% of streams are requested for 20% of the most popular media content according to some embodiments;

[0035] Figure 1 B (Prior art) is a network diagram showing a tiered content delivery network topology; [0036] Figure 2 is a functional diagram of network entities in an Internet Protocol Television (IPTV) network according to some embodiments;

[0037] Figure 3 illustrates a plurality of subscriber data records managed by IPTV middleware according to some embodiments;

[0038] Figure 4 illustrates a subscriber data record according to some embodiments;

[0039] Figure 5 illustrates a user data record according to some

embodiments;

[0040] Figure 6 illustrates a Virtual Locker (VL) record according to some embodiments;

[0041] Figure 7 illustrates a remote control device according to some embodiments;

[0042] Figure 8 is a flowchart for a method of operation of a server computer according to some embodiments;

[0043] Figure 9 is a flowchart for a method of operation of a server computer according to some embodiments;

[0044] Figure 10 is a flowchart for retaining CatchUp Television (TV) programs according to some embodiments;

[0045] Figure 1 1 is a flowchart for maintaining VLs for subscribers according to some embodiments;

[0046] Figure 12 illustrates a system for an IPTV network according to some embodiments;

[0047] Figure 13 is a block diagram that illustrates a Service Provider (SP) server including the IPTV middleware of the IPTV network according to some embodiments;

[0048] Figure 14 is a block diagram that illustrates the SP server according to some embodiments;

[0049] Figure 15 is flowchart for a method of operation of a client device of the IPTV network according to some embodiments;

[0050] Figure 16 is a block diagram that illustrates a client device of the IPTV network according to some embodiments; and [0051 ] Figure 17 is a block diagram that illustrates a client device of the IPTV network according to some embodiments.

Detailed Description

[0052] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0053] SPs would like to avoid the investment and complexity of services that use private copy cloud based recordings. However, the SPs would still like to have the numerous advantages of cloud based storage while avoiding the issues caused by maintaining private copies of the same content for multiple users. As such, there is a need to overcome these drawbacks.

[0054] The present disclosure solves these drawbacks. Embodiments of the present disclosure include systems and methods that improve, enhance, or extend CatchUp TV services. In some embodiments, the improved CatchUp TV services uses a shared copy of media content for multiple users. The disclosed embodiments enhance CatchUp TV services by providing a mechanism that extends the period during which media content is made accessible by users. Notably, the advantages of the proposed solution include avoiding significant capital and resource investments of deploying a private copy cloud based recording service.

[0055] The present disclosure introduces the concept of a Virtual Locker (VL) which is a data construct for storing information that identifies, for each subscriber, CatchUp TV program content available for viewing by the subscriber. Other types of information may be stored in the VL, including, but not limited to, subscriber information, subscription information, and information identifying other types of program content. The contents of VLs are typically controlled by the network operator, e.g., in accordance with the subscriber's subscription plan.

[0056] The present disclosure also introduces a new service that is referred to herein as "Managed VL (MVL) of CatchUp TV Content" (hereinafter referred to as the "MVL Service"). As the term is used herein, a VL is "managed" if the subscriber also has the ability to make some individual decisions regarding the content of that subscriber's VL. In one embodiment, a subscriber who can manage his or her own VL may choose what content to add to or remove from the VL, subject to the limitations of that subscriber's subscription. For example, a subscriber who has access to a limited subset of channels would not normally be allowed to add to his or her VL a program from a channel other than that limited subset.

[0057] Figure 2 is a high level example of functional network entities in an IPTV network 10 according to some embodiments of the present disclosure. It should be noted that, although Figure 2 illustrates an IPTV network, the same principles may be applied to other distribution architectures, such as TV over IP, TV over Internet, cable TV, and so on. The VL paradigm is agnostic to the access mechanism to application or audio/visual pipe.

[0058] In the embodiment illustrated in Figure 2, an IPTV Terminal Function / Over the Top Terminal Function (ITF / OTF) 12 provides a terminal function in the IPTV network 10. It is the entity that consumes content (e.g., a client device). Additionally the ITF/OTF 12 hosts a portal front end which presents a User Interface (Ul) through which end users interact with the IPTV middleware 14, which provides the MVL Service.

[0059] In the embodiment illustrated in Figure 2, a portal back end 16 provides an interface between the ITF/OTF 12 and the services and

applications of IPTV middleware 14. In one embodiment, portal back end 16 presents a Ul to the end user via the portal front end of the ITF/OTF 12 (e.g., the client device). The portal back end 16 and/or the IPTV middleware 14 may reside at one or more servers remote from client devices. [0060] In the embodiment illustrated in Figure 2, a network head end 18 transmits a transport stream 20 for Linear/Broadcast TV (LTV) content broadcasts. A network head end 18 represents an encoder / transcoder / encryptor that would prepare the broadcast stream before multicasting (or other mechanism) of the channel related A/V stream to end user devices.

[0061] In the embodiment illustrated in Figure 2, an Electronic Program Guide (EPG) source 22, which in some cases is the same as the content provider, provides Extensible Markup Language (XML) metadata for LTV content. The EPG source 22 provides program guide metadata in an agreed- upon format, like XML TV, Tribune, or similar. In one embodiment, that metadata is pushed (via B2B APIs or a shared folder) towards the middleware 14, where parsers read the data and process / convert it into a middleware specific canonical form and store it for future usage. Examples of future usage include (but are not limited to) offering the EPG to end user for program guide view, using the EPG to auto schedule series recording program recordings, using the EPG to auto schedule catchup/restart recordings and/or adjusting already existing schedules because the EPG program run length changed during an EPG ingest that includes updated program information.

[0062] In the embodiment illustrated in Figure 2, an LTV application 24 manages the LTV offerings including individual channel offerings and channel package offerings. It interfaces with the portal back end 16 to generate an EPG grid for the end users.

[0063] In the embodiment illustrated in Figure 2, a VoD content provider 26 provides VoD assets to the IPTV middleware 14. The VoD metadata is ingested by the VoD application 28 to create VoD catalogues and VoD offerings for the operators. The VoD catalogues are presented to the end user via the portal back end 16. The VoD application 28 manages the purchase and rentals of True VoD (TVoD) and coordinates the granting of entitlements in Conditional Access (CA) systems (not shown).

[0064] In the embodiment illustrated in Figure 2, a CatchUp TV network recording application 30 is a functional entity that coordinates with a CatchUp TV application 32 to capture a LTV transmission travelling via transport stream 20 from the network head end 18 into storage 34. The CatchUp TV application 32 then coordinates with the VoD application 28 to create the VoD offerings for on-demand consumption. The CatchUp TV application 32 provides

administrative functions for the operator to select the LTV programming which will support the CatchUp TV service.

[0065] In the embodiment illustrated in Figure 2, a VL Management (VLM) application 36 provides the logic for the end users to manage referenced content to their VLs. The VLM application 36 provides the business logic as described further below.

[0066] In the embodiment illustrated in Figure 2, a subscriber profile manager 40 provides the logic for operators and end users to manage subscription data for subscribers and end users.

[0067] In the embodiment illustrated in Figure 2, a Pay-Per-View (PPV) application 42 manages PPV offerings.

[0068] In the embodiment illustrated in Figure 2, a VoD pump 44 is part of the Content Delivery Network (CDN). In one embodiment, the VoD pump 44 represents a streaming server for VoD that has access to a shared volume (storage) where all the VoD content exists, e.g., VoD assets 46. The same infrastructure can be used to stream nDVR / Timeshift /catchup or other form of on-demand content assets towards CDN. The VoD pump 44 provides VoD content on demand, e.g., upon receiving a request for such content from a content consumer. The VoD pump 44 acts as an origin for the CDN, since the same content might be played multiple times by multiple users, in which case the CDN may cache the first copy that is loaded from the origin.

[0069] In one embodiment, the MVL service includes the VL repository 38 for storing and maintaining VLs that improve, enhance, and/or extend CatchUp TV services as indicated above, and as detailed below. A VL is a logical record associated with an end user. It is created for a subscriber and its associated users who are provisioned with the MVL service. The VL repository 38 may be a database, a memory, a table, or other means for storing the VLs. The VL repository 38 may be separate from VLM application 36, as in the embodiment illustrated in Figure 2, or it may a component of VLM application 36. Likewise, the VL repository 38 may be a component of the IPTV middleware 14, as in the embodiment illustrated in Figure 2, or it may be separate from IPTV middleware 14.

[0070] Figures 3 through 6 show aspects of the IPTV middleware data model embodiment of the VL. A VL may contain references to previously broadcast programming or programming to be broadcast in the future.

[0071] Figure 3 illustrates an exemplary set of subscriber data records 48 persisted by the IPTV middleware 14 according to an embodiment of the subject matter described herein. In the embodiment illustrated in Figure 3, each subscriber data record 48 may be associated with a VL.

[0072] Figure 4 is an example of a format for the subscriber data record 48 according to an embodiment of the subject matter described herein. In the embodiment illustrated in Figure 4, the content of the subscriber data record 48 includes a subscriber name (e.g., "John Doe") that is associated with an identification number, channel package subscriptions, SVoD subscriptions, TVoD purchases, and PPV purchases. Note that a subscriber may have multiple user data records. For example, the subscriber of Figure 4 includes the user data records of "Joe Doe," "Mary Doe," and "Junior Doe."

[0073] Figure 5 shows a user data record 50 for "John Doe" according to an embodiment of the subject matter described herein. In the embodiment illustrated in Figure 5, there is an association of a VL Identifier (ID) along with the attribute of VL size allocation. As shown, for example, "John Doe" is associated with a VL ID "VL_123" and has a VL size allocation of 1000 hours.

[0074] Figure 6 is an example of a VL record 52 according to an

embodiment of the subject matter described herein. In the embodiment illustrated in Figure 5, within the VL record, there are reference records 54 for previously broadcast programs and future broadcast programs. In one embodiment, programs are identified by a program ID. As shown, for example, the VL ID "VL_123" includes several previously broadcast program items and several future broadcast program items. The items that previously broadcast amount to 100 hours of used allocation for VL_123, as shown. The hours of used allocation for VL_123 may be increased as the future broadcast programs become previously broadcast programs that have been captured by the

CatchUp TV services.

[0075] Previously broadcast programming is analogous to successfully recorded programs. For example, a previously broadcast program is one that is accessible by an end user only after the program has broadcast. Programming to be broadcast in the future is analogous to a future scheduling of recording. For example, a program to be broadcast is designated by an end user to be made accessible by the user after the program has broadcast. After the program has broadcast, its reference can or will be moved to the previously broadcast programming list.

[0076] An amount of reference content may be measured as a quantity of time and/or disk space occupied by programs listed in the VL. The amount may be assigned to particular end user(s) on a subscription basis. For example, an end user can purchase more or less time/space based on their need. As such, the programming designated by an end user in a VL is limited by the amount of reference content for that particular end user.

[0077] The amount of reference content designated to an end user may be enforced by one or more policies. For example, an end user may be denied for adding a reference for a particular program to the user's VL when adding the reference would exceed an available amount of reference content for that particular end user. In some embodiments, policies to enforce the amount of referenced content in a VL will be applied as an enforced quota size. In some embodiments, policies may restrict access to program content based on a subscription profile that defines channels that the subscriber is and is not allowed to access.

[0078] The disclosed embodiments may extend the period during which CatchUp TV media content remains available to end users. For example, CatchUp TV SPs will provision all (or as much as possible) programming as CatchUp TV capable and, as such, will digitally record all content in the cloud network. In other words, CatchUp TV services capture broadcast content irrespective of any interest expressed by any particular end users. However, CatchUp TV services usually designate media content for deletion after a predetermined period of time has expired since the media content broadcast. The disclosed embodiments may extend this period of time via the use of VLs.

[0079] In one embodiment, the enhanced CatchUp TV service only captures media content once a program commences its normal broadcast on a Linear TV service. This enables an end user to view a program that is being captured in real time and shift to any timeframe of the program while the program is being captured. After the broadcast of the program is complete, a VoD offering will be created for the program, e.g., after the entire program has been captured by CatchUp TV services, that program is made available to subscribers as a VoD offering. These mechanisms allow immediate time-shift consumption of the program in real time during a broadcast and after a broadcast is complete. This is analogous to being able to time-shift content that is currently being recorded.

[0080] In one embodiment, the disclosed VL is offered to end users so that the end users may manage references of Linear TV content that is of interest to those end users. In contrast with services where an end user normally schedules a recording and manages a recording list, with this new service, an end user maintains a VL containing references to specific programming which are indicative that a user has expressed interest in that specific programming for future consumption. For example, referring back to Figure 6, the VL for a particular end user contains references to specific programs that have previously broadcast and programs that will broadcast in the future. The end user adds references to future broadcast programs to the user's VL, which are then moved to the user's previously broadcast programs once the broadcast of the programs is complete. The amount of reference content (time/size) allocated to the end user will be used to enforce limits the inclusion of future broadcast programs in the VL similar to enforcing a quota. [0081] The disclosed VL can be created directly from the EPG Graphical User Interface (GUI). For example, in some embodiments, an end user can use a remote function (i.e., remote control) functionality to navigate and traverse the EPG grid. Upon identifying/highlighting a program of interest, the end user could add a reference for the program to the end user's VL.

[0082] Figure 7 illustrates an exemplary remote control 56 having function buttons that could be used to control the contents of a user's VL. In the embodiment illustrated in Figure 7, the remote control 56 includes a "+" button 58 to add a program reference to the end user's VL and a "-" button 60 to remove a program reference from the end user's VL.

[0083] The VL record can only include references to programing that the end user normally has access to (e.g., channels provisioned for that end user) and that the SP has identified as part of the end user's MVL CatchUp TV service.

[0084] In one embodiment, only programs that are currently being broadcast or will be broadcast in the future can be added as references in the VL. An end user cannot add references to previously broadcast programs in their VL. This is analogous to the constraint that an end user cannot add a program to recorded content after that program has already been broadcast in the past. In other words, an end user cannot use recording services to travel back in time to record something that the service had not recorded while being broadcast. In some embodiments, various aspects of the disclosed service can be created / offered based on content provider agreements in the specific geography of deployment of service.

[0085] In traditional cloud based recording services, an end user normally deletes a program stored as a recording that is no longer of interest to that end user. For example, an end user may designate a program as "deleted" which causes the recording services to either delete the program or designate that program for eventual deletion. In contrast, with this new service, an end user only removes the reference for the specific programming from the VL that is no longer of interest to the end user. However, removing a reference from a VL does not control whether the referenced program will be deleted from storage. Instead, removing a reference may simply prevent subsequent access to that program by the end user of the VL. After removing the reference from the VL, the amount (size/time) of reference content available to the end user is recalculated similar to how an available quota can be recalculated when a recording is deleted.

[0086] The process for removing content from a VL is analogous to the process for adding content to the VL. To do this, an end user browses the contents of the end user's VL. The end user highlights/selects the reference to the program that is no longer of interest to the end user and the end user removes that reference from the VL by pressing a button on a remote control.

[0087] The process to playout program content referenced in the VL includes an end user browsing the content of the VL and selecting one or more references to content which is to be playout. Upon selecting a reference, a playout Uniform Resource Locator (URL) for the referenced content is requested from the IPTV middleware. As such, the program content is stored/ingested and is offered as an on-demand asset by the SP of the system.

[0088] Unlike cloud based recording services, an end user does not control whether program content referenced in a VL is ever deleted. Instead, the end user controls the inclusion of references in the VL. Note that, even after the playout of the VL referenced client, the reference persists in the VL until it is explicitly removed by the end user. However, adding or removing a reference from a VL does not necessarily designate the referenced content for eventual deletion, even if the referenced content is not included in the VL of any subscriber. Instead, the actual content of the programming shall persist in the IPTV system in accordance to, e.g., business practices of the operator or SP.

[0089] Programming captured by a CatchUp TV service may persist in the IPTV network in accordance with a variety of factors that are not limited to any particular end user. For example, standard CatchUp TV services may store all captured programs for a designated period of time (e.g., seven days) after a broadcast of each respective program has completed. As such, a captured program may remain available to end users from a period beginning with the time of the initial broadcast to a time after broadcast is complete. Upon expiration of the time after broadcast, the captured program is designated for deletion and deleted according to, e.g., business practices of the operator or SP.

[0090] The disclosed embodiments may exclusively enable a SP to designate media content for eventual deletion and forbid all end users from designating any media content for eventual deletion. For example, deleting references to content in a VL does not control whether the referenced content will be designated for deletion. Instead, deleting references removes the end user's expressed interest to the referenced content. The decision to delete or erase referenced content may depend on factors such as the number of end users that express an interest in that content by including the referenced content in their VLs. For example, content may persist in the IPTV network until a number of references to that content in the VLs of subscribers is at or below a threshold (e.g., equal to zero). For example, referenced content may be designated for deletion when, e.g., zero VLs include references to that content (and the default time period for storage of CatchUp TV (e.g., seven days) has expired). Thus, the deletion of media content is not controlled by any particular user, and a SP may consider a variety of factors to determine when to designate media content for deletion.

[0091] The aforementioned process for enhancing CatchUp TV services may be practiced according to a variety of methods that include steps performed by one or more servers or client devices of an IPTV network. One embodiment will be described in Figure 8.

[0092] Figure 8 is a flowchart for a method of operation of a server computer or server computer system according to some embodiments of the present disclosure. In some embodiments, the method of operation of a server computer includes maintaining VLs for subscribers, where the VLs include references to at least a subset of CatchUp TV program(s) (step 100). The method further includes retaining the at least a subset of the CatchUp TV program(s) according to an extended retention policy (step 102), and retaining the CatchUp TV program(s) other than the at least a subset of the CatchUp TV program(s) according to a default CatchUp TV retention policy (step 104).

[0093] In some embodiments, the identified CatchUp TV programs referenced in the VLs include programs that were broadcast before receiving the request, programs currently being broadcast while the request is received, and/or programs to be broadcast after receiving the request. For example, programs that were broadcast before receiving the request to include CatchUp TV programs that are currently retained in storage because a default retention period for those programs has not yet expired. Programs currently being broadcast while the request is received include CatchUp TV programs that are currently being captured in storage. Lastly, programs that are broadcast after receiving the request include CatchUp TV programs that are scheduled for future broadcast.

[0094] Figure 9 is a flowchart for a method of operation of a server computer according to some embodiments of the present disclosure, showing in more detail step 100 from Figure 8, maintaining VLs for subscribers. In some embodiments, the method of operation of a server computer comprises creating VLs for CatchUp TV content (step 200), providing subscription based control of the CatchUp TV content (step 202), enabling subscribers of the CatchUp TV content to manage records contained in the VLs (step 204), and providing playout of programs referenced in the records contained in the VLs (step 206). As such, by using the building blocks/primitives of VoD and CatchUp TV services, embodiments of the disclosed service avoid having to offer specific and dedicated recording services for end users.

[0095] Figure 10 is a flowchart for retaining CatchUp TV programs according to some embodiments of the present disclosure, showing in more detail step 102 from Figure 8. Again, in some embodiments, this method is performed by a server computer (or a server computer system). This process is performed to determine a retention policy for a CatchUp TV program. In the embodiment illustrated in Figure 10, the server computer starts by determining whether a default retention period for a particular CatchUp TV program has expired (steps 300, 302). If the default retention period for the CatchUp TV program has not expired (step 304), then the server computer retains the CatchUp TV program in storage, i.e., it does not designate the program for deletion. The process returns to step 302 and is repeated for the next CatchUp TV program.

[0096] However, if the default retention period for the CatchUp TV program has expired (step 304), then the server computer determines whether the program is subject to a default retention policy (step 306). If the program is not subject to a default retention policy, the server computer operates to determine whether a counter value for references in VLs associated with the CatchUp TV program is equal to or less than a predetermined threshold (step 308). If the counter value is greater than a predetermined threshold (e.g., zero), then the server computer retains the CatchUp TV program in storage and the process returns to step 302 and is repeated for the next CatchUp TV program. For example, if at least one VL contains a single reference linked to the CatchUp TV program, then the CatchUp TV program is retained for an extended period of time. On the other hand, if the counter value for the CatchUp TV program is equal to or less than the predetermined threshold, then the CatchUp TV program is designated for deletion (step 310). The CatchUp TV program may then be deleted immediately or as otherwise desired by the network operator.

[0097] If, at step 306, the program is subject to the default retention policy, then, because the default CatchUp TV time has expired, the program is designated for deletion (step 310), skipping step 308.

[0098] In some embodiments, the predetermined threshold is always a value equal to zero such that programming is retained for an extended period of time when the counter value for a corresponding program is any value greater than zero, and retained for a default period of time when the counter value equals zero. Further, if the default period of time has already expired when the counter value changes to zero, then the corresponding program may be immediately designated for deletion.

[0099] Figure 1 1 is a flowchart that illustrates a process for maintaining the VLs for subscribers according to some embodiments of the present disclosure, showing in more detail step 204 from Figure 9, enabling subscribers of the Catch Up TV content to manage records contained in their VLs. In some embodiments, this process is performed by a server computer (or a server computer system). In the embodiment illustrated in Figure 1 1 , the process includes receiving a request from a client device for adding or removing one or more CatchUp TV programs (which may also be referred to as media content items) to the subscriber's VL (step 400). The request may be for a specific CatchUp TV program(s) (e.g., a request for a specific program or TV program series as selected by the subscriber via an EPG presented to the subscriber at the client device) or a request that includes one or more criteria for identifying one or more CatchUp TV programs (e.g., actor/actress name, director, content (e.g., FIFA soccer or World Cup soccer)).

[00100] The server computer determines whether the request is a request to add or remove (step 402). Upon receiving a request to add one or more

CatchUp TV programs to the subscriber's VL, the server computer identifies CatchUp TV program(s) that match the request (step 404). Here, the matching CatchUp TV programs may include past programs that have already been recorded and are available via the CatchUp TV service, programs currently being broadcast and recorded for the CatchUp TV service, and/or programs to be broadcast in the future that are to be recorded for the CatchUp TV service. For example, a subscriber may submit a request to add a reference to the

subscriber's VL where the reference is indicative of interest in World Cup soccer games. The server computer searches and identifies past, current, and/or future broadcasts of World Cup programs that are included in the CatchUp TV service. Notably, in some embodiments, if the request is a request to add a specific program or series of programs, then step 404 may not need to be performed, in which case step 404 is optional. In some embodiments, the server computer intentionally avoids searching and/or identifying past CatchUp TV programs.

[00101] The server computer then adds a reference(s) to the subscriber's VL for the CatchUp TV program(s) that match the request (step 406). For example, a reference(s) linked to World Cup soccer games is added to the subscriber's VL. In one embodiment, the server computer increments a counter for each matching CatchUp TV program (step 408). For example, a counter for each identified World Cup soccer game is incremented to reflect an increased interest in the World Cup programs. After the counter is incremented, the process returns to step 400.

[00102] In the event that the request is to remove program(s) from the subscriber's VL (step 402), the server computer identifies one or more CatchUp TV programs matching the request (step 410). As with step 404, this step may be optional in some embodiments where the request identifies the specific CatchUp TV program(s) to be removed. The server computer then removes the reference(s) to the matching CatchUp TV program(s) from the subscriber's VL (step 412). The server computer decrements a counter for each of the matching CatchUp TV programs removed from the subscriber's VL (step 414). After the counter is decremented, the process returns to step 400.

[00103] In some embodiments, the predetermined threshold for a program is a non-zero value that is determined by a network operator to show that there is not enough (insufficient) interest in the program. Notably, in the embodiments of Figures 10 and 1 1 , interest in CatchUp TV programs is expressed by the corresponding counters. However, these counters are only an example. Any suitable mechanism for tracking the expressed interest of a CatchUp TV program in the VLs of the subscribers can be used.

[00104] In some embodiments, the end users may be notified when program(s) referenced in their VLs are available on CatchUp TV or when the size limit of their respective VLs has reached a critical threshold (e.g., nearing maximum capacity). As such, end users can be alerted to the state of programs of interest and the status of their VLs.

[00105] The embodiments detailed above describe mechanisms for providing a new service called MVL of CatchUp TV content service. As such, the embodiments detailed above provide methods, devices, and systems that operate to improve, enhance, and/or extend CatchUp TV services by using existing VoD and/or CatchUp TV technology. As a result, the disclosed embodiments enable the use of shared copies of media content, which eliminates redundancy to improve the use and efficiency of an IPTV network.

[00106] Figures 12 through 16 illustrate an IPTV system and various components as referred to above with respect to the disclosed embodiments. For example, Figure 12 illustrates an IPTV system 10 according to some embodiments of the present disclosure. The IPTV system 10 may be formed from a combination of one or more servers and/or one or more client devices. As shown, the IPTV system 10 includes client devices 62-1 , 62-2, and 62-3 (generally referred to herein collectively as client devices 62 and individually as client device 62), and a SP server 64 including IPTV middleware, all

interconnected via a network 66 (e.g., the Internet). In this example, the client devices 62 include a laptop computer 62-1 , a STB 62-2, and a mobile device 62-3. However, these are only examples. The client devices 62 can be any suitable type of device that can be used to access CatchUp TV content and/or a VL from the SP server 64.

[00107] The concepts and embodiments disclosed herein are not limited to any particular type of network and may be utilized in any suitable type of wired, wireless, and/or cellular network. For example, the IPTV system 10 may include a cellular communications network such as a Long Term Evolution (LTE) (i.e., LTE or LTE-Advanced) cellular communications network.

[00108] Figure 13 is a block diagram of the SP server 64 according to some embodiments of the present disclosure. In one embodiment, the SP server 64 includes a VL creation module 68, a subscription control module 70, a subscriber management module 72, and a playout module 74, each of which is implemented in software that is stored in a computer readable medium (e.g., memory) and executed by a processor of the SP server 64. In one

embodiment, the VL creation module 68 is operable for creating VLs for storing references to a subset of CatchUp TV programs, the CatchUp TV programs comprising scheduled content from a linear TV service that is recorded on network resources at time of broadcast and made available for consumption by subscribers upon request. CatchUp TV programs may also be referred to herein as "CatchUp TV program content" and/or "CatchUp TV content." In one embodiment, the subscription control module 70 is operable for providing subscription based control of the CatchUp TV content. In one embodiment, the subscriber management module 72 is operable for enabling subscribers of the CatchUp TV content to control the content of (e.g., to manage records contained in) their VLs. Lastly, in one embodiment, the playout module 74 is operable for providing playout of programs referenced in the records contained in the VLs.

[00109] Figure 14 is a block diagram of the SP server 64 according to some embodiments of the present disclosure. In the embodiment illustrated in Figure 14, the SP server 64 includes one or more processors 76 such as, for example, one or more Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), and/or Field Programmable Gate Arrays (FPGAs), memory 78, and a network interface 80 for communicatively connecting to the network 64. In some embodiments, the functionality of the SP server 64 is implemented in software stored in the memory 78 for execution by the one or more

processors 76. In some embodiments, the SP server 64 may include additional components responsible for providing additional functionality, including any of the functionality identified above and/or necessary to support the solutions described above.

[00110] In some embodiments, a computer program is provided including instructions which, when executed by the at least one processor 76, cause the at least one processor 76 to carry out the functionality of the SP server 64 according to any one of the embodiments described herein. In one

embodiment, a carrier containing the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as the memory 78).

[00111] Figure 15 is flowchart for a method of operation of a client device of the IPTV network according to some embodiments of the present disclosure. In the embodiment illustrated in Figure 15, the process includes: accessing CatchUp TV subscription services (step 500); enabling a user of the client device to manage content included in a VL, the content including references to CatchUp TV programs (step 502); and providing for viewing of CatchUp TV content referenced within the VL (step 504).

[00112] Figure 16 is a block diagram of a client device 62 according to some embodiments of the present disclosure. In the embodiment illustrated in Figure

15, the client device 62 includes a CatchUp TV subscription module 82, a VL module 84, and a CatchUp TV viewing module 86, each of which is

implemented in software that is stored in a computer readable medium (e.g., memory) and executed by a processor of the client device 62. In one

embodiment, the CatchUp TV subscription module 82 is operable to access CatchUp TV subscription services. In one embodiment, the VL module 84 is operable to enable end users to manage references of content included in a VL. Lastly, in one embodiment, the CatchUp TV viewing module 86 is operable to provide for viewing referenced content that is being rendered.

[00113] Figure 17 is a block diagram of a client device 62 according to some embodiments of the present disclosure. In the embodiment illustrated in Figure

16, the client device 62 includes circuitry that operates to cause the client device 62 to implement the methods and functionality described herein. In one example, the circuitry can be in the form of processing means, which may include one or more processors 88 (e.g., one or more CPUs, one or more

ASICs, and/or one or more FPGAs), memory 90, and a network interface 92 for communicatively connecting to the network 66. The memory 90 may contain instructions executable by the one or more processors 88 whereby the client device 62 operates according to any of the embodiments described herein. In some embodiments, the client device 62 may include a display 94 for viewing referenced content being rendered. In some embodiments, the client device 62 may include additional components responsible for providing additional functionality, including any of the functionality identified above and/or any functionality necessary to support the solutions described above.

[00114] In some embodiments, a computer program is provided including instructions which, when executed by the at least one processor 88, cause the at least one processor 88 to carry out the functionality of the client device 62 according to any one of the embodiments described herein. In some

embodiments, a carrier contains the aforementioned computer program product. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as the memory 90).

[00115] The following acronyms are used throughout this disclosure.

ASIC Application Specific Integrated Circuit

CA Conditional Access

CATV Cable Television

CDN Content Delivery Network

CPU Central Processing Unit

CRTC Canadian Radio-Television and Telecommunications

Commission

DVR Digital Video Recorder

EPG Electronic Program Guide

FCC Federal Communications Commission

FPGA Field Programmable Gate Array

GUI Graphical User Interface

ID Identifier

IP Internet Protocol

IPTV Internet Protocol Television

ITF Internet Protocol Television Terminal Function

ITV Internet Television

LTE Long Term Evolution

LTV Linear/Broadcast Television

MVL Managed Virtual Locker

NDVR Network Digital Video Recorder

OTF Over the Top Terminal Function

PLC Power Line Communication PPV Pay-Per-View

PVR Personal Video Recorder

QoS Quality of Service

SD Secure Digital

SP Service Provider

SSD Solid State Drive

STB Set Top Box

SVoD Subscription Video on Demand

TV Television

TVoD True Video on Demand

Ul User Interface

URL Uniform Resource Locator

USB Universal Serial Bus

VoD Video on Demand

VL Virtual Locker

VLM Virtual Locker Management

XML Extensible Markup Language

[00116] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.