Method and apparatus for processing requests for recording content

A method and apparatus are disclosed for processing content recording requests. The method includes producing a prioritized set of recording requests from all pending recording requests, analyzing the prioritized set of requests with respect to available resources, and producing a list of content requests to be excluded from a recording schedule due to resource constraints. Content recording is performed based on results of the analysis.

TECHNICAL FIELD

This invention relates to a method and apparatus for processing requests for recording content, and specifically, for processing requests for recording content or programs with time and/or resource conflicts.

BACKGROUND

Providers of media content, such as cable television and satellite television, now offer their subscribers the ability to record content for later playback. Such recording typically occurs by way of a recording device, such as a disk drive, located within or external to, a set-top box or other content selection device at the customer premises. Alternatively, such recording can occur by way of a recording device within the media content provider's network, which conceivably spans multiple networks operated by multiple media content providers. To simplify the discussion, the term “Digital Video Recorder” or “DVR” will hereinafter refer to such a recording device, irrespective of whether it is located on the customer premise or within the network of the media content provider.

When a subscriber schedules recordings of content on a DVR, the recordings may overlap in time causing a potential recording conflict. Various factors can complicate the resolution of these potential recording conflicts. Thus, a need exists for a technique for processing recording requests with program time overlaps subject to resource constraints.

SUMMARY OF THE INVENTION

Embodiments of the present principles provide a method and apparatus for processing content recording requests by analyzing a prioritized reduced set of requests and resolving conflicts in the recording requests. Another embodiment provides a computer readable medium containing instructions that, when executed, causes a method to be performed for processing content recording requests.

One embodiment provides a method for processing requests for content recording, which includes: providing a prioritized reduced set of recording requests from a total number of pending recording requests, in which each recording request in the prioritized reduced set has a time overlap with at least one other recording request in the prioritized reduced set, and the prioritized reduced set has fewer recording requests than the total number of pending recording requests. The method includes analyzing the prioritized set with respect to resource constraints to identify recording requests to be excluded from a recording schedule, scheduling requests for recording based on results of the analysis; and recording content according to scheduled requests.

Another embodiment provides a video recorder, which includes an input stream processor; a controller coupled to the input stream processor; and a storage device coupled to the controller. The controller is configured for receiving recording requests, producing a prioritized set of overlapping recording requests from all pending recording requests, and analyzing the prioritized set with respect to available resources; and, based on analysis results, identifying recording requests to be excluded from a recording schedule.

Yet another embodiment provides a non-transitory computer readable medium comprising instructions that, when executed by a processor, causes a process to be performed. The process includes: providing a prioritized reduced set of recording requests from all pending recording requests, each recording request in the prioritized set having a time overlap with at least one other recording request; analyzing the prioritized reduced set with respect to available resources to identify recording requests to be excluded from a recording schedule; scheduling requests for recording based on results of the analysis; and recording content according to scheduled requests.

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. The drawings are not to scale, and one or more features may be expanded or reduced for clarity.

DETAILED DESCRIPTION

FIG. 1depicts a block schematic diagram of an exemplary content selection device10, hereinafter referred to as a set-top box (STB), configured for processing recording requests with program time overlaps and resource constraints according to a method of the present invention, and subsequently recording content based on a schedule of processed requests. In one embodiment, the set-top box10ofFIG. 1includes the DVR as described above. However, other configurations for the set-top box10and DVR may also be used. For example, the functionalities may be located in separate “boxes” or units at a customer premise, as parts of a Local or Wide area network or located in a Cloud or internet.

The set-top box10ofFIG. 1includes an input signal receiver12. The input signal receiver12can comprise one of several known receiver circuits used for receiving, demodulating, and decoding signals received from one of several possible networks including over the air, cable, satellite, Ethernet, fiber, phone line networks, and so on. Selection of a desired input signal for retrieval by the input signal receiver12may occur, for example, in accordance with user input provided through a control interface or touch panel interface14. Touch panel interface14can include an interface for a touch screen device. Touch panel interface14can also include an interface to a cellular phone, a tablet, a mouse, or a remote control (not shown), or the like. One ordinarily skilled in the art also recognizes selection may occur by with other techniques such as signal availability, time selection, and so on.

The input receiver12provides a decoded output signal to an input stream processor15. The input stream processor15performs the final signal selection and processing, and serves to separate video content from audio content for the content stream. An audio processor16converts the audio from the received format, such as compressed digital signal, to an analog signal. An audio interface18receives the analog audio and distributes the audio to a display device (not shown) or audio amplifier. Alternatively, the audio interface18can provide a digital signal to an audio output device (not shown) or to the display device using a High-Definition Multimedia Interface (HDMI) cable or alternate audio interface such as via a Sony/Philips Digital Interconnect Format (SPDIF). The audio interface18can also include amplifiers (not shown) for driving one more sets of speakers. The audio processor16also performs any necessary conversion for the storage of the audio signals.

A video processor20receives the video from the input stream processor15. The video signal can have one or more formats. The video processor20converts the video content, as necessary, based on the input signal format. The video processor20also performs any necessary conversion for the storage of the video signals.

A storage device22can store input audio and video content. The storage device22allows later retrieval and playback of the content under the control of a controller24and also based on commands, e.g., navigation instructions such as fast-forward (FF) and rewind (RW), received from a user interface28and/or the touch panel interface14. As non-limiting examples, the storage device22can comprise a hard disk drive, one or more large capacity integrated electronic memories, such as static RAM (SRAM), or dynamic RAM (DRAM), or may be an interchangeable optical disk storage system such as a compact disk (CD) drive or digital video disk (DVD) drive.

The converted video signal from the video processor20can originate from either the input stream processor15or from the storage device22. The video processor20provides the converted video to the display interface26. The display interface26further provides the display signal to a display device of the type described above. In an example embodiment the display interface26can comprise an analog signal interface such as red-green-blue (RGB) or a digital interface such as HDMI.

In one example, the bus links the controller24to several of the components of the set-top box10, including the input stream processor15, audio processor16, video processor20, storage device22, and a user interface28. The controller24performs various functions, including managing the conversion process for converting the input stream signal into a signal for storage on the storage device22or for display, as well as managing the retrieval and playback of stored content. Furthermore, as will be described below, the controller24processes requests for recording media content with program time overlaps, and schedule recordings subject to resource constraints.

The controller24has access to a control memory30(e.g., volatile or non-volatile memory, including RAM, SRAM, DRAM, ROM, programmable ROM (PROM), flash memory, electronically programmable ROM (EPROM), electronically erasable programmable ROM (EEPROM), etc.) for storing information and instruction code for controller24. The control memory30can include several possible embodiments, such as a single memory device or, alternatively, more than one memory circuit communicatively connected or coupled together to form a shared or common memory.

To program the set-top box10to record content, a user enters commands via the user interface28or through the touch panel interface14to request the recording of content. For example, a user may be located at a restaurant and program the set-top box10to record content via a cell phone. Various alternative methods may also be used to program the recording of content, such as user preferences or viewing habits, where there is no direct user interaction in programing the content to be recorded.

In one embodiment, the user will enter priorities for the content to be recorded. In an alternative embodiment, the content to be recorded may be automatically prioritized according to user preferences, viewing habits, or the like.

When, for example, a user enters commands via the user interface28or through the touch panel interface14to record selected content, the recording requests can overlap in time (i.e., the requested programs have time overlaps). However, simply because two recording requests overlap in their program times does not necessarily prevent execution of both requests. For example, depending on user priorities and/or resource constraints, two recording requests may have program time overlap, but may not actually conflict so as to preclude satisfying both requests. In other words, program time overlap in recording requests alone is not determinative of whether a true conflict exists.

The controller24is configured to process recording requests according to different criteria or rules applicable to various situations. In one situation, the controller24determines which recording request to execute by examining the recording requests with program time overlap and identifying those overlapping requests for which no true conflict exists. For example, two recordings on the same service and/or channel could overlap in time but not give rise to an actual conflict because the same resource can be used for both recordings. In this discussion, a true or actual conflict refers to a situation in which two or more requested recordings would require the same system resource within a same time period, and there is insufficient resource to fulfill or satisfy at least one of the requests. A recording request refers to a request for content or program, which is made available on a given channel providing a specific service. A service can be defined by a program (content) and a channel for broadcasting the program. The channel and/or program has certain parameters or characteristics associated with the program broadcast, e.g., program time, data format (SD, HD, 2D, 3D), among others.

To illustrate, assume a request to record two back to back programs on the same channel; with the first recording set to end five minutes late and the second recording set to begin five minutes early. This would create a 10 minute overlap in the two requests, but the overlap would not require additional resources and would not result in a true conflict, because both requests can be satisfied by a single tuner to record the entire time period covering both requests.

In another scenario, the controller24determines which recording request to execute by examining the overlapping recording requests (i.e., requests for which the programs overlap in time) and resolving conflicts among those overlapping requests by taking into account the priorities of the content to be recorded (or priorities associated with the requests). For example, recording requests with the lowest priority will not undergo execution when an actual conflict exists, i.e. when there is insufficient resource to record all requested programs within a given time period.

In yet another scenario, the controller24takes into account resource constraints of, for example, the set-top box10, the DVR, the media content provider or any combination thereof. Resource constraints can involve more than simply limiting recording to a certain number of simultaneous recordings. For example, a set-top box10(with a DVR) may contain two cable and two ATSC tuners. With the set-top box10configured in this manner, scheduling three recordings that all require cable tuners at the same time would result in a conflict. In contrast, scheduling three recordings that require two cable tuners and an ATSC tuner would not give rise to a conflict. In another example, use of a hardware demultiplexer may be required to parse data during recording for storing indexing data. In this case, if only 4 hardware demultiplexers are available, a limitation would exist of a maximum of 4 simultaneous recordings regardless of tuner availability. In this embodiment, the number of recording requests with program time overlap, together with the type and availability of resources required for each request, are considered in processing the requests and resolving conflicts in these requests.

In another example, for an IPTV network with limited bandwidth, the bitrate of each service provider of the content requested for recording is considered. For example, 25 MB/s link is available and 10 MB/s for each HD channel and 5 MB/s for each SD channel are required. In this case, the sum of channels should not exceed 25 MB/s. This means that the bandwidth would allow recording of at most two HD channels, or up to five SD channels. A mix of channels may also be recorded, for example, one HD channel and three SD channels at the same time. Thus, in resolving potential conflicts for the overlapping recording requests, a low bitrate SD channels may be recorded rather than a higher bitrate HD channels, or a combination of SD and HD channels can be recorded in order to maximize the use of available resources.

The controller24ofFIG. 1will use various parameters or factors in processing recording requests with time overlap in the requested programs, and to determine whether or not there is an actual conflict by taking into account resource constraints as well as assigned priorities when resolving conflicts in the recording requests. Thus, global constraints, i.e., constraints in the recording system that are not specific to any event or service, can also limit the maximum number of recordings due to input/output (I/O) constraints or other resource limitations. Such constraints may include, for example, the capacity limit for downstream throughput of a network interface, or the recording speed of a file system.

FIG. 2illustrates a method200for processing recording requests with program time overlaps subject to resource constraints. As shown in block202, a prioritized data set or list of requests is generated from a total number of pending recording requests (i.e., from all requests waiting to be scheduled for recording). Each request with a program time that overlaps with at least one other program in another request will be included in the prioritized set. Any requests that do not have program time overlap (i.e., no time conflicts) with any other request can be scheduled for recording, and are excluded from the prioritized set. In this case, the prioritized set will only be a subset of the pending requests. This prioritized set with less than the total number of pending requests is also referred to as a reduced data set. If each pending request has a program time overlap with at least one other request, then the prioritized set will include all pending requests. In this unusual situation, embodiments of the present invention will not provide any time-saving benefits compared to other known or conventional approaches.

In block204, each request in the prioritized data set is analyzed or evaluated with respect to available resources to identify those requests that should be excluded from a recording schedule. In other words, these are requests that cannot, at this time, be scheduled for recording due to various constraints, including availability of resources such as hardware components, bandwidth, and/or service-related constraints such as rules of operation from service providers. In one implementation, a “do not schedule” list can be created to include all such requests. This “do not schedule” list is re-computed every time that a schedule change is made, e.g., if a new recording request is received, or if an existing recording request is changed or cancelled.

In block206, requests are processed or scheduled for recording based on results of the analysis from block204. For example, any requests that are not on the “do not schedule” list can be scheduled for recording. Optionally, a recording schedule can be established for those requests that can be satisfied within the requested time.

In block208, content or programs are recorded according to the scheduled requests from block206.

FIGS. 3-4illustrate an example of processing recording requests, including resolving potential or actual conflicts, using the approach ofFIG. 2.FIG. 3shows a process300, corresponding to block202ofFIG. 2, for generating a prioritized and reduced data set340of recording requests from an initial data set310that includes all recording requests at a given time. The prioritized and reduced data set340, which includes all requests having a time overlap with at least one other request, and whose services are different from each other, will be analyzed using process400inFIG. 4(corresponding to block204ofFIG. 2) to determine if they can be scheduled for recording. This set of data is allowed some error, which may result in extra data in the set to be evaluated, but should not exclude data that need to be evaluated for potential conflicts.

In the example ofFIG. 3, a single database query can be used to provide an initial data set containing all pending recording requests, and a “join” process is used to generate a prioritized and reduced data set. Advantageously, a single database query minimizes the number of database accesses, and can significantly speed up the time required to complete a global conflict resolution. Thus, an appropriate SQL® (Structured Query Language) query can be used to generate a data set of all pending recording requests from a database.

In this example, the reduced data set340is obtained by joining the initial data set310with itself, subject to the constraint that entries requesting different services with an overlap in time will be joined. Depending on specific situations, other approaches can also be used for generating the reduced data set340. As an example, assume that a system only allows scheduling to occur for a given time interval, e.g., a 5-minute block, and a data set is stored in memory with the events or services scheduled for recording during each 5-minute block. If such a data structure is already in place for another purpose, it might be easier to simply iterate the in-memory data set to identify blocks containing more than one event, and to generate a reduced data set using an operation that is different from the database join operation discussed above.

Block302shows a table or database entries310that includes an identifier (id) for each recording request; a start and end time associated with the recording request; a service identifier; and a priority of the requested content recording. The service identifier is used to identify various parameters associated with a requested program, including, for example, a channel, one or more attributes or characteristics such as recording formats, content provider or content source.

At block304, a join operation is performed on the records shown in table310such that requests for recording with different services are joined with each other. This example assumes that there are two different services “a” and “b” (e.g., with different channels, content providers, and so on), although more services could exist. At block302, recording requests in the table for which the services are different are joined, e.g., with additional entries added to table310to form another table320.

To better illustrate the join operation of table210with itself, two copies of table310are presented below as Table A and Table B.

In this join operation, each record in Table A is joined with a record in Table B for which the services are different. Thus, the first row or record in Table A (ID=1 and service designation “1”) is joined with the third and fourth rows in Table B (with service designations “3” and “2”, respectively). Similarly, the second row in Table A is joined with the third and fourth rows in Table B because the service for this row in Table A is different from the services of rows 3-4 in Table B. The third row in A (with service designation “3”) is joined with rows 1 and 2 in Table B (with service designation “1”), and so on. The result is table320shown inFIG. 3, where each parameter is shown with prefix “a” or “b” to distinguish between the two groups of requests from Tables A and B respectively.

After joining the records for the two groups of requests with different services, the lists of requests undergo filtering at block306to yield a reduced set of overlapping recording requests, which is shown in table330. Specifically, the reduced set includes only requests for which there is a time overlap between request “a” and request “b”. Other rows in table320for which there is no time conflict between requests “a” and “b” are excluded in table330because these requests can be fulfilled. At block308, the reduced set of overlapping recording requests is ordered by priority, e.g., in decreasing order of priority, as shown in table340, with “4” being the highest priority. The process for determining which “a.id” recordings will be fulfilled is discussed below.

FIG. 4illustrates a process400to be applied to the prioritized, reduced data set340to determine which requests cannot be scheduled for recording. This process can be performed by the controller24ofFIG. 1.

At block402, two empty lists or groups (List1and List2) are created, and processing begins with the first entry in the prioritized reduced data set340of overlapping requests. In subsequent steps, List1will be populated with recording requests for which no actual conflict exists (i.e., resource is available for this request) notwithstanding a time overlap, and thus, can be scheduled for recording. List2will be populated with requests that cannot be scheduled for recording due to actual conflicts, e.g., insufficient resource in the requested time period.

At block404, the first entry in the prioritized, reduced data set340is examined, e.g., by controller24ofFIG. 1, to determine if sufficient resources exist to execute the recording request identified by a.id. This determination is done by assuming that all requests present in both the b.id column of the first entry and List1(i.e., intersection of the data sets defined by b.id and List1) will be recorded, and thus, will have resources allocated to these recordings. Note that these are requests that have a time overlap with the “aid” request (shown in b.id column), but have already been scheduled for recording (shown by its presence in List1). Considering the resources allocated to these scheduled requests, if there is still sufficient resource to record the current entry in the reduced data set, the request identified by “a.id” will be added to List1, as shown in block406. If there is insufficient resource, the recording request will not be scheduled at this time for recording, and is added to List2instead, as shown in block408.

Using the data set340as an example, when the first row is evaluated, List1will be empty and b.id contains event or program4. Since there are no events that are present in both List1and b.id, this means that no other events will be recorded during the program time of the requested event2(under a.id). An inquiry is made to determine if there are sufficient resources to record event2. Since the answer is yes, event2is added to List1.

In the following round of evaluation, the second row of data set340is examined. List1now contains event2, and bid contains events1and2. Since event2is present in both bid and List1, event2will be recorded. An inquiry is made to determine, given the resources required for event2, whether there will be sufficient resource to record event4(under aid). If so, event4will be added to List1. Otherwise, it will be added to List2.

At block410, an inquiry is made as to whether the end of the prioritized and reduced list of requests has been reached, e.g., whether the current “a.id” entry is the last row in table340. If not, the process goes to block412in which the next row in the reduced list of requests is selected for processing in block404as discussed above.

The process of examining each entry in prioritized reduced data set340continues until all entries have been examined as determined at block410. At block414, List2will be a complete list of recording requests that will not be recorded, e.g., to be excluded from a recording schedule. All other requests not in List2are to be scheduled for recording. Based on this information, recording requests that are free of actual conflicts (in time and necessary resource) can be scheduled for recording by the recording device. Since List1is only a partial list of requests to be recorded (e.g., other requests absent in the reduced set340will be scheduled for recordings because there are no time conflicts), it can be discarded at this stage.

In practice, the process200ofFIG. 2is performed whenever a new request is received, i.e., whether to record a new program or to update or change an existing scheduled recording (e.g., any change in the time of recording, program, channel, recording format, and other recording-related parameters). Each time that the process200is triggered, the entire set of pending requests will be examined, including requests that have previously been excluded for scheduled recordings due to program time overlap and resource constraints. This method has various advantages over other possible alternatives or prior art approaches, as explained below with reference toFIGS. 5-6.

FIG. 5illustrates recording requests involving five television programs P1-P5, with various time overlaps between 6 pm and 8 pm. The programs P1-P5are also labeled with their respective priorities1through5, with 1 being the lowest priority, and 5 being the highest priority. Assuming that a set-top box with DVR has two tuners and thus can record two programs simultaneously, the two programs with the highest priorities, i.e., program P5and P3, are selected or scheduled to be recorded. However, program P4(having a priority of 2) will not be recorded because it conflicts with programs P1and P3, both of which are scheduled for recording because of having higher priorities than program P4. On the other hand, since program P2overlaps in time with only one program request (P1), it can be scheduled for recording (using a second tuner) despite having the lowest priority.

FIG. 6shows the same programs P1-P5as inFIG. 5being requested, and an additional request for program P6with a priority6(i.e., the highest priority among the requested programs) and having time overlaps with programs P3and P5. In this case, programs P5and P6have the highest priorities and are scheduled for recording. However, unlike the scenario inFIG. 5, program P3will no longer be scheduled for recording because both tuners will be used for programs P5and P6. Scheduled recordings for programs P1, P2and P4are also different fromFIG. 5, because both programs P1and P4will now be scheduled for recording by virtue of their higher priorities compared to P2.

Thus,FIGS. 5-6show that an addition of a single new recording request can result in changes that cascade through the entire schedule. In other words, resolving conflicts is not as simple as examining only the time range covered by the new recording request. Instead, the entire schedule of recording requests may have to be evaluated based on program times, priorities and resource constraints.

Although other approaches can also be used to solve this conflict resolution problem, the method and example discussed inFIGS. 2-4provide distinct advantages over other alternatives.

For example, one alternative is a recursive solution that first evaluates only the newly added or changed recording request and then expands the range of the evaluation in successive recursive evaluations by including other requests that have time overlaps with the new request. In each pass of evaluation, the requests with time overlaps are examined with respect to program priorities and resource constraints to determine which requests can or cannot be recorded. This evaluation process is repeated until a situation is reached, in which no additional schedule changes (compared to the previous round) are required. This approach can be fast in some cases, but in cases where many rounds of recursive evaluations are required, it can be very slow and time-consuming.

Another alternative is to iterate over the entire schedule and effectively evaluate every entry in the prioritized schedule as to whether there is sufficient resource to record the particular requested program (i.e., perform the inquiry as in box404ofFIG. 4). This is slow because every entry in the schedule will have to be examined, even if only a few entries may need to be changed.

Compared to these alternatives, the method of the present invention provides an improved or more efficient solution by first reducing the set of data that must be analyzed or evaluated, prioritizing the reduced data set, and performing the analysis on the prioritized, reduced data set.

This method provides improved performance because it is readily adaptable to changes in complex conflict scenarios. In a real-life system, determining if an actual conflict exists can depend on many different factors such as tuner availability, available disk space, total bit-rate of requested channels, among others. The criteria used to determine if a true conflict exists may also vary based on implementation or even based on the service provider. In this invention, the decision making regarding whether a true conflict exists based on resource availability is isolated to box404inFIG. 4. All other steps inFIGS. 3-4are always the same, regardless of any specific resource constraints that may be imposed by a particular hardware platform or service provider. This makes it easy to apply the design to multiple hardware platforms and multiple service providers because the only part of the implementation that may need to be customized for a particular hardware device or service provider is the evaluation done in step404. By isolating this evaluation to box404, it is possible to implement a generic solution that will work for many different service providers in many different set top box designs without substantial modifications.

The various embodiments disclosed herein can be implemented as hardware, firmware, software executed by a processor, controller or machine, or any combination thereof. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit or non-transitory computer readable medium (e.g., hard drive, removable storage, read-only memory, random accessible memory, among others), to be uploaded to, and executed by, a machine comprising any suitable architecture. In one embodiment, program instructions are stored in the computer readable medium such that, when executed by one or more processors, will cause a method of the present invention to be implemented as discussed above. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), a memory, and input/output interfaces. The computer platform may also include an operating system and microinstruction code. Various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit.

The block diagrams in the different embodiments illustrate the architecture, functionality, and/or operation of some possible implementations of apparatus and methods. It will be understood that various modifications can be made. For example, one or more elements may be combined, supplemented, modified, or removed to produce other implementations. In some cases, one or more functions may occur in different orders from those shown in the figures. Accordingly, these and other implementations are contemplated by this application and are within the scope of the following claims.