US 20090052870 A1
A system stores a first permission parameter associated with a first user of a set of digital video recorders (DVRs) and at least a second permission parameter associated with a second user of the set. The second permission parameter defines a different level of permission for controlling the set than the first permission parameter. At least one server receives a first request to control the set from the first user and a second request to control the set from the second user. The set is controlled in accordance with: (i) the first request, based on the first permission parameter, and (ii) the second request, based on the second permission parameter. The controlling includes at least communicating with the set over a network. Techniques are also provided for directly obtaining information on a DVR in real time over a content network
1. A method for controlling a set comprising at least one digital video recorder; said method comprising the steps of:
storing at least a first permission parameter associated with a first user of said set and at least a second permission parameter associated with a second user of said set, said second permission parameter defining a different level of permission for controlling said set than said first permission parameter;
receiving, at least one server; a first request to control said set from said first user and a second request to control said set from said second user; and
controlling said set in accordance with: (i) said first request, based on said first permission parameter, and (ii) said second request, based on said second permission parameter, said controlling comprising at least communicating with said set over a network.
2. The method of
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
8. The method of
9. A method for controlling at least one digital video recorder interconnected with a content-based network, said method comprising the steps of:
querying at least one server to obtain program data from said server and DVR data from said digital video recorder;
receiving said program data from said server and said DVR data from said digital video recorder, said DVR data being obtained from said digital video recorder substantially in real time over said content-based network;
displaying said program data and/or said DVR data on a separate device, in communication with said content-based network; and
controlling said at least one digital video recorder by selecting a user-operable function from said program data and/or said DVR data on said separate device
10. The method of
11. The method of
12. The method of
13. A system for controlling at least one digital video recorder with another device, said system comprising:
a content-based network coupled to the at least one digital video recorder; and
a DVR control application module coupled to said content-based network and the device and configured to:
obtain program data;
obtain DVR data from the digital video recorder, said DVR data being obtained from the digital video recorder substantially in real time over said content-based network;
facilitate display of said program data and/or said DVR data on the device; and
control the at least one digital video recorder by receiving a selection of a user-operable function from said program data and/or said DVR data on the device
14. A system for controlling a set comprising at least one digital video recorder, said system comprising:
a content-based network coupled to the set;
an identity management module configured to store at least a first permission parameter associated with a first user of said set and at least a second permission parameter associated with a second user of said set, said second permission parameter defining a different level of permission for controlling said set than said first permission parameter; and
a DVR control application module coupled to said content-based network and said identity management module and configured to:
receive a first request to control the set from said first user and a second request to control the set from said second user; and
control the set in accordance with: (i) said first request, based on said first permission parameter; and (ii) said second request, based on said second permission parameter, said controlling comprising at least communicating with the set over said content-based network
15. The system of
16. The system of
17. The system of
18. The system of
19. A system for controlling a set comprising at least one digital video recorder, said system comprising:
at least one server;
means for storing at least a first permission parameter associated with a first user of the set and at least a second permission parameter associated with a second user of the set, said second permission parameter defining a different level of permission for controlling the set than said first permission parameter;
means for receiving, at said at least one server, a first request to control the set from said first user and a second request to control the set from said second user; and
means for controlling the set in accordance with: (i) said first request, based on said first permission parameter, and (ii) said second request, based on said second permission parameter; said controlling comprising at least communicating with the set over a network.
20. A system for controlling, from a separate device, at least one digital video recorder interconnected with a content-based network, said system comprising:
at least one server;
means for querying said at least one server to obtain program data from said server and DVR data from the digital video recorder;
means for receiving said program data from said server and said DVR data from the digital video recorder; said DVR data being obtained from said digital video recorder substantially in real time over the content-based network;
means for displaying said program data and/or said DVR data on the separate device, in communication with the content-based network; and
means for controlling the at least one digital video recorder by selecting a user-operable function from said program data and/or said DVR data on the separate device.
The present invention relates generally to communications systems and methods, and, more particularly, to techniques fox remote control of a digital video recorder (DVR) or the like through a communications network such as, for example, a cable television network (or other content network), a wireless network such as a cellular network, a Transmission Control Protocol/Internet Protocol (TCP/IP) network, a DOCSIS® (Data Over Cable Service Interface Specification) network (registered mark of Cable Television Laboratories, Inc., 400 Centennial Parkway Louisville Colo. 80027, USA), and the like.
With the advent of digital communications technology, many TV program streams are transmitted in digital formats. For example, Digital Satellite System (DSS), Digital Broadcast Services (DBS), and Advanced Television Standards Committee (ATSC) program streams awe digitally formatted pursuant to the well known Moving Pictures Experts Group 2 (MPEG-2) standard. The MPEG-2 standard specifies, among other things, the methodologies for video and audio data compression allowing for multiple programs, with different video and audio feeds, to be multiplexed in a transport stream traversing a single transmission channel. A digital TV receiver may be used to decode an MPEG-2 encoded transport stream, and extract the desired program therefrom.
In accordance with the MPEG-2 standard, video data may be compressed based on a sequence of groups of pictures (GOPs), made up of three types of picture frames, namely, intra-coded picture flames (“I-frames”), forward predictive frames (“P-frames”), and bilinear flames (“B-frames”). Each GOP may, for example, begin with an I-flame which is obtained by spatially compressing a complete picture using discrete cosine transformation (DCI). As a result, it a transmission error or a channel switch occurs, it is possible to resume correct decoding at the next I-frame. The GOP may represent additional flames by providing a much smaller block of digital data that indicates how small portions of the I-flame, referred to as macroblocks, move over time.
An I-flame is typically followed by multiple P- and B-flames in a GOP. Thus, for example, a P-frame occurs more frequently than an I-frame by a ratio of about 3 to 1. A P-flame is forward predictive and is encoded from the I- or P-flame that precedes it A P-frame contains the difference between a current flame and the previous I- or P-flame A B-flame compares both the preceding and the subsequent I- or P-frame data. The B-flame contains the average of matching macroblocks or motion vectors. Because a B-flame is encoded based upon both preceding and subsequent flame data, it effectively stores motion information.
Thus, MPEG-2 achieves its compression by assuming that only small portions of an image change over time, allowing the representation of these additional flames to be quite compact. Although GOPs have no relationship between themselves, the flames within a GOP have a specific relationship which builds off the initial I-frame.
The compressed video and audio data are typically carried by continuous elementary streams, respectively, which are broken into access units or packets, resulting in packetized elementary streams (PESs). These packets are identified by headers that contain time stamps for synchronizing, and are used to form MPEG-2 transport streams. For digital broadcasting, multiple programs and their associated PESs are multiplexed into a single transport stream. A transport stream has PES packets further subdivided into short fixed-size data packets, in which multiple programs encoded with different clocks can be carried. A transport stream not only comprises a multiplex of audio and video PESs, but also other data such as MPEG-2 program specific information (sometimes referred to as metadata) describing the transport stream. The MPEG-2 metadata may include a program associated table (PAT) that lists every program in the transport stream. Each entry in the PAT points to an individual program map table (PMT) that lists the elementary streams making up each program. Some programs are open, but some programs may be subject to conditional access (encryption), and this information (i.e., whether open or subject to conditional access) is also carried in the MPEG-2 transport stream, typically as metadata.
The aforementioned fixed-size data packets in a transport stream each carry a packet identifier (PID) code. Packets in the same elementary streams all have the same PID, so that a decoder can select the elementary stream(s) it needs and reject the remainder. Packet-continuity counters may be implemented to ensure that every packet that is needed to decode a stream is received.
The well-known H.264/MPEG-4/AVC (Advanced Video Coding) standard is noted for achieving very high data compression and employs basic principles similar to those of MPEG-2, with a number of features that are enhanced, compared to MPEG-2, as will be familiar to the skilled artisan.
Use of digital video recorders (DVRs), also known as personal video recorders (PVRs), such as the TiVo® device (registered mark of TiVo Brands LLC, Alviso, Calif.) and the R Replay TV® device (registered mark of Digital Networks North America Inc., Pine Brook, N.J.), is ubiquitous. Such devices may provide some benefits to TV viewers. For example, a prior art DVR allows a user to record his or her favorite TV programs for later review, and to exercise a season-pass-like option wherein every episode of his or her favorite program is recorded for some period. Such devices may automatically record programs for the user based on his or hex viewing habits and preferences. The presentation of the recorded programming content can be manipulated by exercising rewind, pause, skip and/or fast-forward functions (hereinafter referred to as “trick mode” functions) furnished by the DVR.
U.S. Pat. No. 7,073,189 of McElhatten, et al. is entitled “Program guide and reservation system for network based digital information and entertainment storage and delivery system.” The disclosure of the aforesaid U.S. Pat. No. 7,073,189 of McElhatten, et al. is expressly incorporated herein by reference for all purposes. A “network PVR (NPVR)” (also referred to as an NDVR (Network Digital Video Recorder)) service allows the user to per form the analogous DVR functions through use of a network, rather than via a local DVR at the user premises. Unlike a DVR device, the NPVR service allows a user to “reserve” past and future programs for his or her review, even if such reserved programs were not identified by the user before their broadcast.
Note that “trick modes” or “trick play” refer to one or more of fast forward, reverse, pause, skip, and the like. Note also that an NDVR can be distinguished from a DVR in that the latter, storage of programs and the like is local to the DVR, while in the former (NDVR) case, such storage is at the server or head end level
US Patent Application Publication 20060062544 of Southwood et al discloses an apparatus and method for programming a video recording device using a remote computing device. In particular, a recorder device, such as a VCR, digital video recorder, or the like, that can be programmed from a remote computing device, such as a personal computer mobile personal digital assistant, or cell phone, over a wired and/or wireless network is disclosed. The recording device includes a recording medium configured to record audio and/or video content. A controller, which is coupled to the recording medium, is configured to control the writing of audio and/or video content onto the recording medium and to control the leading of audio and/or video content stored on the recording medium. The recording apparatus also includes a network interface configured to receive recording commands generated by a remote computer and transmitted via a network coupled to the network interface and to provide the received recording commands to the controller, the recording commands defining a selected programming content to be recorded on the recording medium.
Principles of the present invention provide techniques for controlling at least one digital video recorder. In one aspect, an exemplary method (which can be computer implemented) for controlling a set of one or more DVRs includes the step of storing at least a first permission parameter associated with a first user of the set and at least a second permission parameter associated with a second user of the set. The second permission parameter defines a different level of permission for controlling the set than the first permission parameter. The method further includes receiving, at least one server, a first request to control the set from the first user and a second request to control the set from the second user, and controlling the set in accordance with: (i) the first request, based on the first permission parameter, and (ii) the second request, based on the second permission parameter. The controlling includes at least communicating with the set over a network.
In another aspect, a method for controlling at least one digital video recorder interconnected with a content-based network includes the steps of querying at least one server to obtain program data from the server and DVR data from the digital video recorder, and receiving the program data from the server and the DVR data from the digital video recorder. The DVR data is obtained from the digital video recorder substantially in real time over the content-based network. The method further includes displaying the program data and/or the DVR data on a separate device, and controlling the at least one digital video recorder by selecting a user-operable function from the program data and/or the DVR data on the device.
In yet another aspect, a system for controlling at least one digital video recorder with another device includes a content-based network coupled to the at least one digital video recorder; and a DVR control application module coupled to the content-based network and the device. The DVR control application module may be configured to obtain program data, obtain DVR data from the digital video recorder (the DVR data being obtained from the digital video recorder substantially in real time over the content-based network), facilitate display of the program data and/or the DVR data on the device, and control the at least one digital video recorder by receiving a selection of a user-operable function from the program data and/or the DVR data on the device.
In still another aspect, a system for controlling a set comprising at least one digital video recorder includes a content-based network coupled to the set, and an identity management module configured to store at least a first permission parameter associated with a first user of the set and at least a second permission parameter associated with a second user of the set. The second permission parameter defines a different level of permission for controlling the set than the first permission parameter. The system further includes a DVR control application module coupled to the cable television network and the identity management module and configured to receive a first request to control the set from the first user and a second request to control the set from the second user, and control the set in accordance with: (i) the first request, based on the first permission parameters and (ii) the second request, based on the second permission parameter. The controlling includes at least communicating with the set over the content-based network.
As used herein, “facilitating” an action includes performing the action, making the action easier, helping to carry the action out, or causing the action to be performed. Thus, by way of example and not limitation, instructions executing on one processor might facilitate an action carried out by instructions executing on a remote processor, by sending appropriate data or commands to cause or aid the action to be performed.
An exemplary embodiment of an apparatus, according to yet another aspect of the invention, can include a memory and at least one processor coupled to the memory. The processor can be operative to facilitate performance of one or more of the method steps described herein. In still another aspect, an apparatus or system can comprise means for performing the various method steps. The means can include one or more hardware modules, one or more software modules, or a mixture of one or more software modules and one or more hardware modules.
One or more method steps of the present invention can be implemented in the form of an article of manufacture comprising a machine readable medium that contains one or more programs which when executed implement such step(s).
Techniques of the present invention can provide substantial beneficial technical effects. For example, one or more inventive embodiments provide direct access to a DVR allowing more accurate determination of programs currently recorded and/or scheduled for recording, as compared to accessing a persisted copy instead of the DVR per se.
These and other features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
One or more inventive embodiments may be implemented, by way of example, and not limitation, within the context of delivering programming content to users through a broadband communications network, such as a cable TV network. Users may have DVR capability in their homes, either within a set-top box (SIB) or as a stand-alone component. In some cable TV networks, selected programs or program channels may be afforded a network personal video recorder (NPVR) service to enhance a users enjoyment of programming content. One or more embodiments of the invention relate to remote control of a DVR; however, for purposes of generality we discuss networks that may have NPVR functionality, inasmuch as one or more embodiments of the invention may be implemented within networks not having NPVR functionality, as well as within networks that also have such NPVR functionality. In accordance with the NPVR service, broadcast programs (or at least those broadcast programs afforded the NPVR service) are recorded at a head-end of a cable network when they are delivered to a user at a set-top terminal. Thus, the user not only may “reserves” for review a future program and a previously broadcast program, but may also restart an in-progress program, since such program has been recorded at the head-end regardless of any user request. That is, the NPVR service obviates the need for the proactive effort otherwise required of a typical DVR user, which includes deciding and actively electing in advance what shows to record. In addition, the NPVR service furnishes trick mode functions for manipulating a presentation of recorded programming content. In one or mole embodiments of the invention, users are enabled to remotely control DVRs from personal computers, remote wireless devices, and the like. Such capability is advantageous where NPVR capability is not available, or as a supplement to NPVR capability. Thus, as noted just above, remote DVR control aspects of the invention can be implemented in systems with or without NPVR services. US Patent Application Publication 2005-0034171, kind code A1, of Robert Benya, published Feb. 10, 2005, entitled “Technique for delivering programming content based on a modified network personal video recorder service,” is expressly incorporated herein by reference for all purposes, and discloses a non-limiting example of a network that can be modified to implement one or more inventive techniques.
An exemplary service, within which one or more aspects of the invention may be employed, will now be described. It should be understood that the described service is exemplary and not meant to be limiting, as one or more embodiments of the invention may be employed with other services, differing from that described.
Head-end 105 receives programs and services from various providers and sources, e.g., analog and digital satellite sources, application servers, media servers, the Internet, and the like. Analog and digital satellite sources typically provide the traditional forms of television broadcast programs and information services. Application servers typically provide executable code and data for application specific services such as database services, network management services, transactional electronic commerce services, system administration console services, other application specific services (such as stock ticker, sports ticker, weather and interactive program guide data), resource management services, connection management services, subscriber care services, billing services, operation system services, and object management services Media severs provide time-critical media assets such as MPEG-2 encoded video and audio, MPEG-2 encoded still images, bit-mapped graphic images, Pulse Code Modulation (PCM) digital audio, three dimensional graphic objects, application programs, application data files, etc. Although specific examples of programs and services which may be provided by the aforementioned sources are given herein, other programs and services may also be provided by these or other sources.
Acquisition/Staging (A/S) processor 109 in head-end 105 processes program materials including, e.g, TV program streams, from one or more of the aforementioned sources in analog and digital forms. Analog TV program streams may be formatted according to the National Television Standards Committee (NISC) or Phase Alternating Line (PAL) broadcast standard. Digital TV streams may be formatted according to the Digital Video Broadcasting (DVB), Society of Cable Telecommunications Engineers (SCTE), or Advanced Television Systems Committee (AISC) standards. Processor 109, among other things, extracts program content in the analog and digital TV streams and reformats the content to form one or more MPEG-2 encoded transport streams. Such reformatting may even be applied to those received streams already in an MPEG-2 format. This stems from the fact that the digital content in the received MPEG-2 streams is typically encoded at a variable bit rate (VBR). To avoid data “burstiness,” processor 109 in a conventional manner re-encodes such digital content at a constant bit rate (CBR) to form the aforementioned transport streams Head-end 105 communicates with one or more remote DVR layers 190 for providing remote control of one or mole DVRs (for example, integral with or associated with set-top terminals 158-1 to L). Exemplary functionality of layers 190 is described hereinafter with respect to
An MPEG-2 transport stream contains multiple program streams with different video and audio feeds multiplexed for transmission through the same transmission channel. The program streams representing individual programs are identified by respective program identifications (IDs) within a transport stream. It should be noted at this point that the term “transmission channel” should not be confused with a “program channel.” A “transmission channel” signifies a designated frequency band through which a transport stream is transmitted. On the other hand, a “program channel” signifies the source of the program material selected by a user to view. For example, a user may select program channel 2 to view program material provided by CBS, program channel 23 to view program material provided by Home Box Office (HBO); program channel 32 to view program material provided by Music Television (MTV), and so on. At this juncture, it should be noted that compression techniques other than MPEG-2 may be employed.
In this illustrative embodiment, the transmission channels, each carrying a transport stream, may be 6 MHz bands populating a forward passband, e.g., a 350-750 MHz band, of a coaxial cable, which is allocated for downstream communication from head-end 105 to a given set-top terminal 158
A/S processor 109 may receive “assets” including pre-staged movie videos, news reports, sports events, etc. from content providers. However, processor 109 may also create “assets” in real time while processing received program materials which are not pre-staged by the content providers. In general, an “asset” is a container and/or reference for any object or set of objects that may be desired in order to implement a service, including video, audio, images, application executables, scripts, configuration files, text, fonts, and hypertext mark-up language (HTML) pages (or pointers referencing their storage locations). In addition to the raw content, metadata is also a part of an asset object that describes characteristics of the asset. For example, asset metadata may describe attributes that are inherent in the content of the asset, such as the rating, format, duration, size, or encoding method. Values for asset metadata are typically determined at the time the asset is created, but can also be determined before such time and then populated into appropriate locations when the asset is created.
An asset concerning a program may, in some instances, include trick files associated with the program as well Trick modes and trick files are discussed herein for purposes of providing a detailed description of one particular type of network that can be employed in one or more embodiments of the invention. It is to be emphasized, however, that this is purely by way of example, and inventive techniques can also be implemented in other networks that omit some or all of the described functionality. Still with reference to
For illustrative purposes, assume that TV program 201 in this instance is an initial broadcast program. Processor 109, among other things, collects in a database (not shown) program guide data associated with different TV programs which are not pre-staged (including TV program 201 in this instance) from an application server, which may be different from the sources of the TV programs themselves (as will be discussed below in connection with
Note that, as used herein, “staging” involves the process of converting video streams to a digital (if not already in digital format), constant bit-rate (CBR), appropriate group-of-pictures (GOP) structure (15 or 30), Internet-protocol (IP) format (for multicasting through a network). Staging is applicable to a variety of scenarios, including Switched Digital Video (SDV), Digital/Analog Simulcast, NDVR/NPVR, video over IP/IPTV, and the like, and works in essentially the same fashion in all the exemplary cases.
It should be noted that where program 201 is not an initial broadcast program, which may also be pre-staged, commercial segments 221 and 227 may not contain the commercials originally provided by the program provider. Rather, program 201 may, in some instances be repackaged with after-market commercials, which may be targeted to the user, and which may even be injected anywhere in the program with no regard for original segments 221 and 227 in terms of their timing, duration, or quantity. In the event that program 201 is pre-staged, the program content comes with the corresponding metadata file and trick files associated with the program. Further, in some instances, processor 109 stores the created or pre-staged asset including the metadata file and trick files associated with a program according to its program designation in asset storage (not shown), which may reside in library manager 113 described below.
The transport streams generated by processor 109, which contain live TV programs in this instance, are fed to cache manager 111. The latter includes a cache memory (not shown), e.g., a disk cache, having a memory capacity on the order of terabytes Manager 111 copies the transport streams onto the cache memory, and also forwards the same to library manager 113 for long-term storage. The latter includes library storage having a memory capacity on the order of hundreds of terabytes, much larger than that of the cache memory, such that the cache memory stoles the last Y hours' worth of the IV programs while the library storage stores the last Z hours' worth of the TV program, where the value of Z is much greater than that of Y. It suffices to know for now that use of the cache memory, which affords faster access to its content than the library storage, facilitates a speedy retrieval of a requested program in the event of a “cache hit,” i.e., the requested program being within the last Y hour broadcast. Conversely, a “cache miss” requires locating the requested program in the library storage, thereby incurring a delay in the retrieval of the program.
Network controller 125, among things, assigns resources for transporting program materials to set-top terminals and communicates various data, including system information, to and from the terminals. Upstream data from a set-top terminal 158 to network controller 125 is communicated via a reverse passband, e.g., a 5-40 MHz band, of a coaxial cable. The reverse passband comprises reverse data channels (RDCs) having a 1 MHz bandwidth in this instance, through which quaternary phase shift keying (QPSK) signals containing upstream data are transmitted. It should be noted that the 1 MHz bandwidth allocated for an RDC here is for illustrative purposes only. It will be appreciated that a person skilled in the art may allocate other bandwidths for RDCs, depending on the actual implementation. A set-top terminal utilizes an RDC for sending both application data and control messages. For example, the Digital Audio Visual Council (DAVIC), a standard setting organization, has defined a contention-based access mechanism whereby multiple set-top terminals share an RDC. This mechanism enables the set-top terminals to transmit upstream messages without a dedicated connection to a QPSK demodulator. The mechanism also provides equal access to the set-top terminals that share the RDC, and enables detection and recovery from reverse path collisions that occur when two or more of the terminals transmit an upstream message simultaneously. As also specified by DAVIC, for communications purposes, the set-top terminals and network controller 125 are identified by the Internet protocol (IP) addresses assigned thereto. However, these IP addresses may be randomly assigned each time when system 100 is reconfigured. As a result, the IP address of a set-top terminal 158 or controller 125 may change after a system reconfiguration. Nevertheless, each set-top terminal 158 and controller 125 is also assigned a media access control (MAC) address on a permanent basis, surviving any system reconfiguration.
Downstream data from network controller 125 to a set-top terminal 158 is communicated via forward data channels (FDCs). These channels, often referred to as “out-of band” channels, may, for example, occupy the 70-130 MHz band of a coaxial cable. QPSK signals containing system messages to a set-top terminal 158 are transmitted through an FDC having a 1 MHz bandwidth in this instance. It should be noted that the 1 MHz bandwidth allocated for an FDC here is for illustrative purposes only. It will be appreciated that a person skilled in the art may allocate other bandwidths for FDCs depending on the actual implementations.
When a user at a set-top terminal, say, terminal 158-1, turns on the tuner associated therewith and selects a particular program channel, say, program channel 2, or changes from another channel to channel 2, terminal 158-1, in a well known manner, scans for any transport streams transporting programs to the neighborhood. In system 100, each transport stream is identified by a unique transport stream identification (TSID).
Continuing the above example, once the TSIDs of the transport streams are detected, terminal 158-1 sends, through QPSK modem pool 127, a request for program channel 2 material. Reference should also be had to
Reference should now also be had to
Referring also back to
Network controller 125 may include therein a carrier assignment table which lists, for each carrier, the TSID of the transport stream carried thereby. The carrier identification by network controller 125 at aforementioned step 408 may be achieved by looking up, from the table, the carrier associated with the TSID of the selected transport stream. Based on the requested program channel, network controller 125, at step 409, determines the program ID identifying the program stream representing the requested program material, i.e, program channel 2 material in this instance, which is then multiplexed with other program streams in the selected transport stream. At step 412, network controller 125 communicates, to media processor 119, a first message containing the identity of the modulator in modulator bank 123 which corresponds to the carrier, say, C1, just determined, and the program ID associated with the requested program channel material just determined. At step 415, network controller 125 sends, through QPSK modem pool 127, a second message, responsive to the received request, to set-top terminal 158-1, which is identified by the origination IP (and/or MAC) address in field 309 of request 300. This second message traversing an FDC contains the information concerning the carrier frequency, i.e., CF1 in this instance, to which terminal 158-1 should tune to receive the appropriate transport stream, and the program ID for extracting the desired program stream, representing in this instance program channel 2 material, within the transport stream.
In response to the first message, processor 119 directs cache manager 111 to deliver a copy of the program stream representing the requested program channel material thereto and causes the program stream to be multiplexed with any other program streams already in the transport stream identified by the selected TSID. In addition, processor 119 causes switching unit 117 to switch the resulting transport stream to the modulator corresponding to the carrier C1. Accordingly, the modulator modulates the carrier C1 with the received transport stream, and causes transmission of the modulated carrier through the transmission channel associated with CF1.
Based on the information in the second message, terminal 158-1 tunes to the carrier frequency CF1 to receive the transmitted transport stream, and extracts therefrom the desired program stream, representing program channel 2 material in this instance. In a well-known manner, terminal 158-1 converts the extracted program stream to appropriate signals for the associated TV to play program channel 2 material.
While the program channel 2 material is being played, terminal 158-1 continuously registers the last I-frame identifier in the received transport stream. From time to time, terminal 158-1 sends a “heartbeat” containing the IP (and/or MAC) address identifying terminal 158-1 and the last I-frame identifier to media processor 119. Processor 119 keeps, for terminal 158-1, a record identified by the IP (and/or MAC) address of terminal 158-1, and tracks the program being transmitted to terminal 158-1 and its I-frame progress. When processor 119 no longer receives heartbeats from terminal 158-1, e.g., because of an off state of the terminal, processor 119 may cause the transmission of the transport stream to terminal 158-1 to be halted.
Refer now also to
For example, in memory 610, NVRAM may be used for storage of a usel's settings and set-top terminal configuration settings, such as parental control codes, favorite channel lineups, set-top terminal setups, channel maps, authorization tables, and FDC address assignments DRAM may be used for most application and operating system storage requirements, such as stacks, heaps, graphics, interactive program guide data, marketing data and usage data, and functions such as MPEG-2 video decompression, DOLBY DIGITAL® (registered mark of Dolby Laboratories Licensing Corporation, San Francisco, Calif.) Adaptive Transfer Coding 3 (AC-3) audio decoding, and video manipulation. ROM may be used for storage of the operating system. Flash ROM may be used for storage of resident application software, as well as patches of the operating system and application software, which software and/or patches are downloaded to set-top terminal 158 from head-end 105 after set-top terminal 158 has been deployed at the user's premises.
Processing unit 605 orchestrates the operations of set-top terminal 158. It executes instructions stored in memory 610 under the control of the operating system. Service application manager (SAM) 607 forms part of such an operating system of terminal 158. SAM 607 is responsible for, among other things, monitoring channel change events; administering channel, service and other tables in terminal 158; and maintaining a registry of applications in terminal 158. One such application is the aforementioned Watch IV application 603 which is invoked to service a traditional broadcast channel (or program). Another possible application, mentioned for completeness, is “NPVR TV” application 612 which is invoked to service NPVR enabled channels (or programs), and which may be downloaded from head-end 105 to memory 610. Communication with head end 105 may be through interface 621. Again, the remote DVR control aspects of the invention are applicable to cable TV networks with or without NPVR functionality.
It will be appreciated that the description thus far, in association with
It should be noted at this point that commonly assigned US Patent Application Publication 20070050818, Ser. No. 11/215,942, filed Aug. 31, 2005, of Berger et al. discloses a Remote DVR Manager. The disclosure of the aforesaid US Patent Application Publication 20070050818, Ser. No. 11/215,942, filed Aug. 31, 2005, of Berger et al. is expressly incorporated herein by reference for all purposes. Further, it should also be noted at this point that reference is made herein, in one or more examples, to a cable television network service provider; however, this is but one non-limiting example of a content (network) provider, which may include, by way of example and not limitation, a cable service provider, a direct broadcast satellite service provider, or a telephone service provider offering video content services.
Attention should now be given to
The user at block 718 wishes to control his or her DVR 158. An application residing in tier 790 can access an electronic program guide block 750, for example, via Internet 762, to obtain an electronic program listing Optionally, such program information is stored in database 760, which obtains it from electronic program guide block 750. As noted elsewhere herein, the functionality in block 750 may be afforded by a third party provider of programming guide services such as Tribune Media; another example is the service provided by GEMS TAR—TV GUIDE INTERNATIONAL, INC. In such services, each program may be identified by a unique program identifier. For example, an episode of “Home Improvement with John and Mary” scheduled to appear on Wednesday Jul. 11, 2007 at 9 PM EDT would have a unique identification number or code associated with it DVRs 158 may typically use such numbers or codes to identify programs to be recorded. Advantageously, the other components of system 700 may also use the same numbers or codes to refer to particular programs to be recorded. When a user employing the web application at block 718 selects a program to record, for example, by clicking on its listing in a program grid, server tier 790 establishes a connection to division head end application server 768, indicating that a certain DVR 158 wants to record a certain program. The program may be identified by the aforementioned number or code. Head end server 768 communicates with the appropriate DVR 158 and instructs it to record the desired program. The communication can be carried out, for example, as described above with respect to
The architecture depicted in
As used herein, “real time” refers to a case where a desired action happens within 30 seconds, and preferably within 5 seconds, from the input intended to cause the action—for example, when a selection on a PC or wireless remote DVR interface screen is clicked, the corresponding action, such as selecting a program for recordation, occurs within the specified time.
Another significant feature that may be included in one or more instances of the invention is the ability to manage a number of users wishing to control the same DVR(s) 158 (by way of example and not limitation, a parent or parents and one or more children living in the same house). It may be desirable to allow some users (for example, children) less authority than other users (for example, parents) in terms of which programs, channels, or ratings of programs may be recorded, which DVRs may be controlled, whether choices of other users can be overridden, and so on. Each of the users may be provided with a different account, or the users may share a single account but have different levels of authority within the account (for example, by providing sub-accounts within an account). In some instances, provision can be made for establishing “super user” permissions, whereby selections made by all other user's may be over-ridden. Such a “super user” may be the individual who initially sets up the account, for example. Other users may be afforded “lesser user” permissions, which may, for example, be provided in one or more classes allowing less and less authority than that of the “super user.” Some examples of conditions that might be established are as follows: all family members can program family room DVR, but only parents can program parents' bedroom DVR; children are allowed to program whatever they wish, but only from a subset of channels, for example, channels showing only wholesome family programming; children cannot see what is programmed on the DVR in the parents' bedroom; children are allowed to program whatever they wish, but only from a subset of ratings, for example, programs rated “TVY” or “TVG” but not those rated “TV14.” The type of functionality described in this paragraph may be advantageously incorporated into identity management server 712. A profile may be stored for each user, in storage accessible to identity management server 712, and such profile may specify the level of permission that such user has to control one or more DVRs in a home or the like. Such profiles may be set up, for example, by having remote DVR application server tier 790 provide a GUI accessible to a super user, for example, via web access per block 718, and such super user may then create identities or the like for other users, such as other family members, and may establish permission levels for such other users.
In order to set up the rules controlling the levels of permission, etc., it is typically necessary to determine how many DVRs 158 are present within the home, so that it can be determined who is allowed to access which DVR(s). Advantageously, the architecture depicted in
Thus, with reference now to
In some instances, as will be discussed in greater detail below, control capability may be available from one or more wireless devices, as indicated at block 792. Such functionality may be provided, for example, by downloading a suitable application to the wireless devices, referred to as a “Mobile Remote DVR Application.”
At block 816, system 700 determines what head end serves the particular user. It will be appreciated that systems other than the exemplary systems 700, 900 described herein may also be used to carry out method steps Larger divisions may have more than one head end. This information may be obtained, for example, from a database in block 768 (not separately illustrated), as shown at block 818. At block 820, system 700 can determine whether the remote DVR 158 is serviceable. This can be carried out, for example, by retrieving information relating to the user's SIBs, via a web service, from head end server 768, as shown at block 822. This results in the generation of a list of one or more DVRs of the user that can be reached. In block 824, system 700 obtains the appropriate channel line-up. In some instances, head ends have multiple channel line-ups, and all those stored in the pertinent head end may be obtained. If there is only a single line-up; it may be presented to the user; if more than one line-up, the user may be queried which line-up he or she has access to. In one or more instances, the line-ups(s) may be advantageously obtained via a web service, as shown at block 826. At block 828, system 700 determines video entitlements, for example, if a premium channel is present in the user's channel line-up, does the user have access to that premium channel? Thus, in some instances, channel line-ups may be filtered based upon a subscription package.
In block 830, system 700 determines which DVR to schedule. As shown at block 832, this question typically arises only when more than one DVR is available; if this is the case, at block 834, the user can be queried regarding which DVR he or she wishes to access. As discussed above, the different DVRs in the user's home may be named. In some instances, the user's selection of or naming of the DVRs may be facilitated by showing him or her the current schedule for that particular DVR (since the user may not know the MAC address of the particular DVR). In block 836, system 700 obtains a list of scheduled recordings, preferably directly from DVR 158, as discussed above. This list may display shows currently recorded and/or shows scheduled to be recorded, and, in one or more embodiments, can be obtained via a web service, as shown at block 838.
In block 840, the user is helped to find something he or she wishes to record, for example, by one or more of display of a channel grid, as at block 842; a browse display (that is, a list of all the programs for the next predetermined time period on a given channel), as at block 844; and a program search (for example, a text search for “football”), as at block 846. The program data can be obtained, fox example, from the EPG data block 750 or the database 760, as shown at block 848. In block 850, the user specifies which program he or she wishes to record. At block 852, system 700 issues instructions to cause the selected program to be recorded; for example, by using a web service that specifies the program identification discussed above, and the identity of the DVR (for example, its MAC address or other indicia), causing the desired program to be placed in the correct DVR's record queue.
It should be noted that in one or more embodiments, it will be advantageous to ensure that electronic program guide data accessed by the web site(s) (or wireless devices) is consistent with guide data on DVRs 158. The majority of DVR users are accustomed to using the electronic program guide (EPG) to set up future recordings. As a result, the EPG is a significant component in one or more embodiments of a remote DVR platform. The EPG should preferably provide access to program information for the same time period as available on the SIB/DVR, fox example, two weeks. This information may be provided using a combination of information cached or information accessed in real time based on a user request (for example, one day cached on the device, such as a mobile device discussed below, and up to two weeks accessible upon a request). The EPG may provide the channel name, channel number, date, show start time, program duration, program rating, program description (containing the same fields that are available on the user's Set Top Box, e.g. title, description, actors, production date, etc), Closed Captioning availability, and secondary audio programming (SAP) availability. The EPG may show dates and times of upcoming repeat episodes of the same or series title, with description, and may show dates and times of upcoming new episodes of the same or series titles, with description. The EPG preferably employs the same information database as the home EPG, and preferably displays the channels and services that are available on the home SIB/DVR The EPG should allow subscribers to purchase additional home video services from the remote application, such as subscribing to new programming packages or other products. For programs that have been previously recorded or are scheduled for recording, the EPG should provide the channel name, channel number, original air date, show start time, program duration, program rating, program description (containing the same information that is available on the users Set Top Box), the “Save until” date, Close Caption availability, and SAP availability.
The EPG may provide a show preview environment that plays previews of recorded or upcoming programs in full screen mode, and may also provide a show preview environment that plays previews of recorded or upcoming programs in Picture-in-Picture mode. The EPG may provide a list of related content on television, video on demand, movies on demand, or other products available from the operator of a cable television network, its business partners, or third parties. Further, the EPG may provide links to related items for purchase, such as digital video disks (DVDs), books, digital media downloads (shows, movies, songs and the like), compact audio disks (CDs), etc. Yet further, the EPG may contain links to guidance from third party sources such as the Internet Movie Database (IMDB) (movies), a web site such as TV.com, Common Sense Media (Family Friendly Ratings), and the like, and the EPG may contain links to related entertainment & news features on a web site operated by the cable television provider, its business partners, or third patties. Even further, the EPG may contain a list of top rated programs, and may recommend program to the user based on a profile or recommendation engine.
Additional notes related to the desirable consistency of EPG data between the STB/DVR and remote DVR application(s), will now be provided. In some instances, a program listings and channel lineups aggregation server can be monitored, maintained and managed in a centralized location on the cable television wide area network. All of the division head end servers 768 in the divisions will send their program listings and channel lineups to this aggregation server on a regular basis, where they can be made available to other applications which may need this data. This exemplary approach can help to ensure that customers see consistent program data and channel lineups in other client applications (e.g., Remote DVR) as they will see on their TV screens at home.
Additional functionality that may be provided within system 700 will now be described. In addition to selecting shows to record from a grid, a user may have the opportunity to select a show to record from search results or the like, to set a reminder for upcoming shows (posted on or sent to a web site, fixed or mobile phone, PDA, and so on), to set a channel and time slot instead of a specific show, and to confirm or cancel recordings. In some instances, functionality is provided wherein a user may select a show for recording by depressing a key while watching the show. Various priorities may be set and changed as desired, for example, selections for whether a program is to be saved or may be written over when space is needed; priority order for series that are scheduled to be recorded; deletion orders for shows to be deleted, and so on. Further, users may be given the choice to modify the start or finish time for recordings already scheduled, the time a recording is scheduled to be retained, set or modify the number of episodes in a series recording that are to be saved, and set or modify whether new episodes or all episodes in a series are to be recorded. The listings of shows already recorded, or scheduled for recording, may be displayed, for example, by date and time or title. A log may be kept of past actual recordings, deletions, and so on, and users may be allowed to review lists of deleted episodes, previously scheduled recordings not recorded due to a conflict and/or due to insufficient disk space. A flag may be provided to indicate recorded shows that will soon be deleted. Users may be given the opportunity to suggest programs to friends and/or relatives, for example, by sending a link to the person's STB, PC, mobile device, etc. (such link might allow the friend or relative to easily schedule the recommended program for recording). Further, a user may be given the opportunity to set up a “wish list” of desired programs or of desired program attributes, and suitable recommendations may then be generated by the system and the user advised of same. Recommendations may be developed, for example, by a recommendation engine, which may recommend shows available by cable television, video on demand, movies on demand, wireless, and may recommend other content opportunities such as digital media downloads (including but not limited to shows, movies, music, wallpapers, ring tones, and games) for Set Top Boxes, PCs, fixed wireless, voice over Internet protocol (VoIP), or mobile wireless devices.
In addition to scheduling recordings, the application may allow the user to schedule a time and date for automated playback of a recording on a DVR connected television set, and/or may allow the user to schedule a time and date for automated playback of a recording on a PC connected by a home network to the DVR, or to a remote Internet-connected PC, where the playback may be from a real time stream from the DVR or a cached file deposited to the wireless device over a wired or wireless connection. The file may require transcoding to a different format. Further, the application may allow the user to schedule a time and date for automated playback of a recording on a mobile wireless device, where the playback may be from a real time stream from the DVR or a cached file deposited to the wireless device over a wired or wireless connection. Again, the file may require transcoding to a different format. Yet further, the application may allow the user to playback a recording on a mobile wireless device immediately using a live stream from the DVR. Yet again, the file may require transcoding to a different format. The application may allow the user to send a copy of a recording to a mobile wireless device for viewing at an unspecified time. Still again, the file may require transcoding to a different format. The application may allow the user to send a copy of a recording to a remote Internet-connected PC for viewing at an unspecified time. As before, the file may require transcoding to a different format.
Thus, a method for controlling at least one digital video recorder interconnected with a content network can include the step of querying at least one server to obtain program data from the server (for example, from block 750) and DVR data from the digital video recorder 158. A further step can include receiving the program data from the server and the DVR data from the digital video recorder. The DVR data can be obtained from the digital video recorder 158 substantially in teal time over the content network (including block 768). Further; the method can include displaying the program data and/or the DVR data on a separate device (for example, the PC in block 718) in communication with the cable television network. As shown in
Furthermore, a system for controlling at least one digital video recorder 158 with another (separate) device, such as the PC in block 718, can include a content network, including block 768, coupled to the at least one digital video recorder 158, and a DVR control application module, such as server tier 790, coupled to the content network and the device, and configured to obtain program data, obtain DVR data from the digital video recorder (substantially in real time over the content network), facilitate display of the program data and/or the DVR data on the device, and control the at least one digital video recorder by receiving a selection of a user-operable function from the program data and/or the DVR data on the device.
In one aspect, exemplary inventive techniques provide a mechanism including a set of processes, a set of interfaces, and a set of logical sequences of events which take place to allow a DVR customer to control his or her DVR using a mobile device such as a cellular telephone, personal digital assistant (PDA), wireless multimedia device, capable of playing audio and/or video content, and the like.
Once it is determined that user 702 has a valid account and is in good standing, user 702 is preferably presented with personalized information. For example, if the user is a resident of Dallas, Tex., the Dallas, Tex. programming guide is displayed on the user's mobile device 704, 706, 708. The mobile devices 704, 706, 708 employ radio frequency (RE) communication, as opposed to infrared (IR) communication of short-range remote device employed within the same room as the DVR 158. Further, if the user has already programmed his or her DVR to record three television programs, such information is also displayed on the user's mobile device 704, 706, 708. Another example of personalized information is the screen background color for the display on the mobile device, which could be set to match that on the home DVR Yet another example of personalization is what the user chooses to see first when he or she logs in (inasmuch as the mobile screen is typically smaller than a PC screen and cannot display everything that is seen on the PC screen). In addition to color and font, it should also be noted that the logical flow of the remote DVR application may also follow what is displayed at home. In essence, the entire user interface of the remote DVR application may be based upon the flow and color scheme of in-home DVR service. Thus, in general terms, the menu shown to the user may be customized (personalized) to take into account the physical geographic location of the DVR 158, fox example, by presenting a program guide associated with that location.
The exemplary system 900 interconnects a number of new and existing sub-systems and supports the processes and the ordering of events needed to provide the desired DVR control functionality. In one or more preferred but non-limiting implementations of inventive techniques, the DVR 158 can be owned and/or operated by a service provider who provides the user's CATV service (such provider may also provide, for example, one or more of e-mail/Internet connectivity, wireless telephone service such as cellular telephone service, and the like). Thus, the service provider can verify, before providing access to system 900, that the user 702 has a DVR, and is current with fees. Furthermore, where user 702 has multiple DVRs 158 in home 716, user 702 can advantageously be provided with capability to select, via mobile device 704, 706, 708, which of the multiple DVRs 158 in home 716 he or she wishes to remotely control. Integration of the remote control function with the service provider is advantageous, and poses interesting requirements for back-end systems integration and process flow support. It should be noted that
A more detailed, block-by-block description of exemplary system 900 will now be provided. Blocks may also be considered to be layers in a system Functionality of blocks and/or layers may be implemented in modules employing hardware and/or software, as discussed elsewhere herein. Block 718 represents a web-based interface. User 702 accesses his or her cable television (CATV) account and controls his or her DVR 158 via a desktop or laptop PC 720, as described above Block 722 represents a user 702 interfacing with a backbone CATV Internet Protocol (IP) network of a service provider, such as a CATV provider. The aforementioned network is represented by IP core 724. Modes of interface include local area indoor WiFi network 726 (represented by a wireless router communicating with device 706 and IP Core 724). Other types of interface could include outdoor WiFi network 728 or an outdoor 3G/4G network 730. Again, these networks (for example, cell towers 732 and/or meshed access points 734) can tie into IP Core 724. Block 736 is similar to block 722, except that in block 722, the various indoor and outdoor networks are provided by the same service provider who operates the aforementioned CATV network, while network 738 in block 736 may be operated by a third party other than the CATV service provider Blocks 722 and 736 are exemplary instances of block 792. A private connection 740 may then be provided to IP Core 724. One non-limiting example of network 738 is an Evolution-Data Optimized or Evolution-Data only, abbreviated as EVDO, network. Thus, in one or more instances, method steps (discussed further below) of obtaining a representation of a request, obtaining a representation of a menu from a back end, and translating the representation, are carried out by a cable television service provider, and the at least one digital video recorder 158 is owned and/or operated by the cable television service provider Remote wireless devices can operate over a wireless network (including, but not limited to, a cellular network) owned and/or operated by the cable television service provider, as at 722, and/or over a cellular or other wireless network owned and/or operated by a (third party) partner of the cable television service provider, as at block 736. In some instances, the cellular or other wireless network may be operated by a third party who is not a partner of the cable television service provider, in a “network agnostic” manner. Examples of types of wireless networks include GSM, CDMA, WiFi, WiMAX, commercial mobile radio service (CMRS), etc.
In one or more embodiments of the invention, the DVR control application is “network agnostic,” that is, the application does not “care” which network it runs on. However, significantly, in one or more embodiments, the application does “care” about the device that it runs on, since mobile devices 704, 706, 708 may have reduced display (screen size, for example), processing, and input/output capability as compared to desktop or laptop computer 720. As long as access to appropriate URLs can be provided, the network used to connect devices to the various front end and back end servers (to be discussed hereinafter) is not necessarily in itself of great concern. Thus, in blocks 718, 722, and 736, user 702 may request a channel line up using a variety of access methods, such as a web-based application, via desktop or laptop PC 720 in block 718; a mobile network operated by the service provider, as at block 722; or a third party network, as at block 736. Remote wireless devices can thus operate over a cellular or other wireless network owned and/or operated by the cable television service provider, as at 722, and/or over a cellular or other wireless network owned and/or operated by a (third party) partner of the cable television service provider, as at block 736.
Attention should now be given to wireless DVR interface block 742, including wireless DVR interface server 744, which is preferably a server running appropriate application software to interface between the front end of system 900, represented by blocks 718, 722, and 736, and the back end of the system, represented by blocks 710, 712, and 746-756. Because computer 720 has quite a bit of display and processing capability, a feature rich browser, and so on, it is relatively easy to move large amounts of data back and forth using extensible mark-up language (XML), hypertext transfer protocol (HTTP), Adobe Flash, and so on, to communicate with back-end servers such as those in block 748 (to be discussed further below). Thus, in one or more embodiments, computer 720 interfaces with block 748 without block 742 functioning as an intermediary. However, mobile devices 704, 706, 708 typically have smaller screen sizes, less memory, and lower processing capability, as compared to computer 720. The solution using computer 720 interfacing directly with block 748 is typically feature-rich and content-heavy. However, the mobile devices typically axe incapable of accepting the XML messages that enable the feature-rich, content-heavy solution.
Advantageously, one or more embodiments of the invention provide wireless DVR interface server 744 (for example, a server interfacing with storage, not separately numbered) in block 742 to enable the mobile devices to interface with back-end elements, such as block 748, that are configured to interface with more powerful computers with greater memory and display capability, such as computer 720, wireless DVR interface server 744 is configured to obtain data feeds from the back end (the data feeds being designed for a browser on personal computer 720, that is, intended for the PC domain), and “tune down” such feeds to be compatible with the capabilities of the mobile devices (e.g., limited memory for storing programming data). For example, instead of providing two weeks of programming data, as would be done for computer 720, wireless DVR interface block 742 might pare the two weeks down to two days worth of programming data. Another example would be an error message. An error message sent from the back end to a PC browser might be formatted in a certain way that appears best on a PC browser. Wireless DVR interface block 742 can reformat the en or message into a format understandable by the mobile devices. In general terms, wireless DVR interface block 742 can retune the content and protocols from a standard back end to PC format, to a mobile format. This may involve, for example, tuning down the amount of data, resolution, and/or messages being delivered. If the functionality of wireless DVR interface block 742 were not provided, all the messages and content generated by the back end and intended for the PC 720 would have to be duplicated to allow interfacing with the mobile devices. However, wireless DVR interface block 742 is set up to translate the protocols, the type of data, and so forth, to allow the back end communications intended for PC 720 to be “tuned down” to work with the mobile devices 704, 706, 708.
In some instances, a user will have the ability to view the programs which have been scheduled to record (possibly only a subset of such programs, such as those that have been scheduled but have not been recorded yet). This list is another example of something that can be scaled down and/or reformatted so that it is optimally exposed for a wireless device. The ability to reformat certain functions according to the constraints and limitations of the wireless network at hand may be afforded; for example, a 4G network may be able to process more data at greater speeds, therefore the amount of data displayed and how it is delivered may be different than, for example, a 3G network, so as to render optimal usage.
Thus, one or more embodiments provide a system and method for remote DVR control, wherein a back end interfaces with a PC, and wherein a wireless DVR interface block is interposed between the back end and lower-featured (as compared to the PC) remote devices to translate messages intended for the PC into a tuned-down format that can be understood by the mobile devices. In general terms, a method (which maybe computer-implemented) for remote control of at least one digital video recorder 158 includes the step of obtaining, from a remote wireless device 704, 706, 708, a representation of a request for remote control access to the DVR. Responsive to the request, a representation of a remote control menu is obtained from a back end (for example, block 748). The representation of the menu is configured for a personal computer type browser on PC 720. The representation of the menu configured for the personal computer type browser is translated, for example, by block 742, to a modified representation of the menu configured for the remote wireless device. Transmission of the modified representation of the menu to the remote wireless device is facilitated. The steps described can be performed, for example, by the wireless DVR interface block 742; the representation of the menu can be obtained by the wireless DVR interface block from, for example, a remote DVR application server of the back end, such as server 764, discussed elsewhere herein. The “modified representation” can be modified, for example, by reducing the channel listing to a shorter time period that that intended for the PC 720, or for tailoring the data for display on a relatively low-resolution display of devices 704, 706, 708, instead of the relatively high-resolution display of PC 720, and so on.
At least one menu selection can be obtained from the remote wireless device; for example, a command to record at least one television program, which might specify, for example, at least a start time, an end time, and a channel selection.
The skilled artisan, given the teachings herein, can code general purpose computers to perform the functions described with regard to the blocks in
By way of review, in blocks 718, 722, and 736, user 702 can request a channel lineup by a variety of methods, including a relatively feature-rich web interface, as at block 718, or via mobile devices, as at blocks 722 and 736. Data from computer 720 may be passed directly to authentication server block 748. Data from mobile devices, per blocks 722 and 736, can be isolated by block 742 before being passed to authentication server 748. In addition to or in lieu of isolating mobile data, block 742 with wireless DVR interface server 744 can perform any one or more of handling proxy username and/or password information, acting as an access gateway and session manager, caching data (for example, for an electronic programming guide (EPG)), and transcoding and/or repurposing messages, such as errors, alerts, notices, and the like. Thus, in some instances, electronic program data is periodically obtained from an external source, such as 750, and such electronic program data is cached in wireless DVR interface block 742. That is, while EPG data may be cached at block 742, it may require periodic updates from block 750 via, for example, block 748 to access the latest programming data.
Tuning now to authentication server block 748, this block can gather user information, such as a user name and password, and authenticate same, for example, by checking blocks 710 and/or 712, which may hold account information about account(s) of user 702. Billing system 710 may also have data on the type of customer premises equipment (CPE) associated with user 702. In some instances, the functionality just described is performed by identity management server 712, which may obtain needed information from billing system 710. User information may be authenticated via appropriate billing queries with block 710. Block 712 may contain master record storage of user login information, and may include single sign on (SSO) capability and digital identity creation and storage. Communication by block 748 with block 710 may be, for example, via XML. Simple Object Access Protocol (SOAP), possibly though an intermediate block 746. Block 746 may provide, for example, single sign-on and/or cross-platform identification capability (for example, the user may have a mobile phone number, an account number with the CATV service provider, cable services authorizations, and the like). Block 746 may retrieve and translate any activity on a subscriber's account which may lead to actionable impact through block 748. For example, a user's service location may have changed, in which case a user now needs to retrieve a new channel line-up, or a customer is now in delinquent status with his or her account, in which case limited or no access may be allowed to the Remote DVR application. Similarly, communication between block 748 and block 712 can be, for example, via XML SOAP A non-limiting example of a communication technique that can be used between the IP core 724 and wireless DVR interface layer 742 is XML over HTTP. Thus, in general terms, in response to a user's access request, a step of facilitating verification that the user of the DVR 158 and wireless device 704, 706, 708 is a valid user can be conducted.
The authentication server block 748 may, in one or more embodiments, include the functionality for allowing remote programming of the DVR 158 via PC 720, such as user authentication, subscription validation, personalized settings display, programming guide retrieval and display, and so on. Since the functionality of block (or layer) 742 is to tune the aforementioned functionality down for the mobile devices, in one or more embodiments, block 742 only needs to communicate with block 748 and the mobile devices. In one or more embodiments, block 748 provides to block 742 a set of application program interfaces (APIs) and feeds (intended for the PC domain) that are in a protocol such as XML. The format of the content in the XML feed that is sent from block 748 to block 744 will be known by block 744. Block 742 will then parse the feed and retune or repurpose it and send it to block(s) 722 and/or 736. In one or more embodiments, block 748 is substantially unchanged as compared to a solution that accommodates only remote control via PC 720 (and not via the mobile devices 704, 706, 708); however, some minimal modification may be needed to interface with block 742 and the mobile devices. This includes the repurposing and modification of the mobile guide (EPG) so as to be formatted in an acceptable manner for each specific device (i.e., limit the amount of EPG data being passed at a time). It also includes the transcoding of notifications and error messages to be sent down to the devices, so as to be considerate of the screen size.
Basic aspects of repurposing and transcoding can include addressing limitations in data size associated with the mobile device, and/or recreating (scaling) back end messages intended for a PC so that they can be more appropriately understood by a mobile device. For Internet communications, content (the raw message) is typically wrapped by protocols such as XML, Slash, and the like. Mobile devices typically do not have browsers that can handle such protocols and so the layer 742 advantageously unwraps the raw messages intended for a PC and re-wraps them in a form appropriate for the mobile client.
Block 748 may be implemented, for example, using an authentication server 758 and a database 760 accessible to the server 758. Block 748 may function as an authentication server and portal, and may perform one or more of authentication and identity management, gathering of set top box information (Media Access Control address (MAC address), Internet Protocol (IP) address, and the like), gathering user information (for example, via a web-based graphical user interface (GUI) accessible on PC 720), creating a digital identity, and so on. Block 748 can communicate with block 750, wherein electronic program guide (EPG) data is available, for example, via Internet 762. The EPG data may include metadata passed to database 760. In some instances, EPG information may be obtained from a third party business partner of the CATV operator, such as Tribune Media Services, as discussed above.
Block 752 can include an application server 764 and a web server 765. Blocks 748 and 752 together form one possible implementation of block 790. In one or more embodiments, each head end 105, as discussed above, may include functionality depicted in block 754, which interfaces with block 752. This functionality may be implemented, for example, on processors depicted in head end 105, or on other processors coupled to them, or some combination thereof. Block 752 is capable of communicating with the DVR set top boxes 158 (e.g., via block 754), and can make APIs into the set top boxes 158 available to block 748. It should be mentioned at this point that the various blocks or layers in
Thus, a user 702 interacting with his or her DVR 158 via PC 720 will see a certain user interface, electronic program guide, a certain amount of data, and have the capability to scroll through and pick programs to record. On a mobile phone or other mobile devices 704, 706, 708, this functionality is advantageously converted, for example, via block 742, to function with the relatively small screen and limited memory of the mobile devices.
Block 754 preferably includes a video network portal 766 and a head end (HE) server 768. A number of servers 768 may be in head-ends of divisions of the CATV service provider; and may send individual program listings and channel line-ups to an aggregation server. Again, functionality in the head end may be implemented on processors depicted in head end 105 or on other processors coupled to them, or some combination thereof. Block 756 can include set top box (with DVR functionality) 158; appropriate control information is passed back to the various layers and servers to effectuate the remote control functionality described herein. In some instances, aggregation server functionality can be provided, for example, within block 764 such an aggregation server can pull together the program listings and channel line-ups from disparate locations such as the head ends.
In view of the discussion herein, it will be appreciated that an exemplary method for controlling at least one digital video recorder, according to one aspect of the invention, includes querying at least one server from a wireless device such as 704, 706, 708, to obtain program data and DVR data. The program data may reside on or be accessible to a server within block 750. The DVR data may reside on DVR 158. Another step may include receiving the program data from the server and the DVR data from the digital video recorder. Further steps may include displaying the program data and/or the DVR data on the wireless device, and controlling the at least one digital video recorder by selecting a user-operable function from the program data and/or the DVR data on the wireless device.
In another aspect, a method is provided for a cable television service provider to offer a consumer a service of controlling at least one digital video recorder owned and/or operated by the cable television service provider. Such method may include the cable television service provider carrying out or facilitating the steps described just above, for example, by interacting with a consumer's wireless device, using at least one server under control of the cable television service provider. Communications with the DVR(s) are preferably carried out over the cable televisions service provider's own cable television network, for example, network 140.
In still another aspect, a system for controlling at least one digital video recorder 158 with a wireless device such as 704, 706, 708, includes a DVR control module, for example, as formed by blocks 748, 752, 710, 712, and 750. Also included is a cable television network such as network 140, which may include blocks such as blocks 754 and 756. The network is coupled to the DVR control module and the at least one digital video recorder. The system also includes wireless DVR interface module 742, coupled to the DVR control module and configured to carry out functionality as described herein.
Exemplary functionality of system 900 will now be described A mobile user 702 may view the latest channel listings downloaded via the EPG of block 750 to a mobile device such as 704, 706, 708. Mobile device 704 may have a mobile DVR control application. In some instances, the user 702 may advantageously select a future program to record with one-touch functionality (for example, appropriate defaults could be stored such that a record command could be executed substantially by a single action, such as a click or depressing a key). Examples of such defaults include: if the show should start/stop on time (or include a 1-15 minute delay), if the recording will be single or series, which DVR to record to, and how the recording should be saved (saved until space is needed or until user deletes recording). The mobile DVR control application (which may include an application in block 742 that interfaces with the mobile devices) passes the DVR control commands received from the mobile device to an application backend, where such DVR control commands may be translated to communicate with the authentication server 758. Note that the backend layers include blocks 752, 754, and 756 “Backend” may be employed, for example, to refer to the components to which commands are sent in order to complete the Remote DVR request.
The aforementioned application backend on block 742 interfaces with the authentication server 758, and the user 702 is authenticated and the billing systems are checked for current user information Server 758 interfaces with, and passes mobile DVR control commands with, backend application servers in block 752. A mobile DVR control “record” command can be passed in this manner. The DVR control command is then sent to video network portal 766 and HE (head end) server 768 in the division head-ends of a CATV service provider. Portal 766 communicates with the DVR 158 through the server 768. Server 768 communicates with the DVR client and sends an appropriate DVR control command to cause recordation of the program selected by the user on the EPG listing. Communication with set-top box/DVR 158 may be via techniques as described above with respect to
As noted, one or more embodiments may permit interface with a wireless network operated by a CATV provider or by a third party, or both. The system 900 may be described, in general terms, in the aforementioned layers:
Specific functionality of one or more non-limiting exemplary embodiments will now be described. The authentication server 758 will process user authentication factors, including username, password, and mobile directory number (MDN) (cellular telephone number). Furthermore, in some instances, server 758 performs various identity management functions such as retrieving account update information when a customer moves to a different location, becomes delinquent in account status, adds a new DVR to his or her service, etc. The logic associated with EPG listing expiration will reside within a cellular phone DVR Control application downloaded to mobile devices such as 704, 706, 708. The passing of usage parameters, such as EPG retrieval, DVR control commands, and the like, will follow the same protocols and logic of that of the PC DVR Control solution (that is, the functionality designed to interface directly with PC 720 without being “tuned down” for the mobile devices). Overall registration functionality for one or more embodiments of the wireless DVR control service can be integrated into a PC-based DVR registration solution. Backend validation factors fox wireless DVR control can include, for example, the username and password as used with the PC DVR Control service, in addition to the MDN which is specific to the mobile phone or device. The username and password can be used to verify customer type and permissions. The wireless DVR interface block 742 will act as an access gateway and session manager to the authentication server 758. Wireless DVR interface block 742 will proxy the username and/or password, cache data (EPG), and format, transcode, and/or repurpose wireless messages or alerts.
One possible example of the aforementioned registration process will now be described PC user 702 navigates to an appropriate online account registration page of the CATV service providers. The user enters required information, by way of example and not limitation, one or more of account number, last name, first name, state, division, and last four digits of social security number and/or driver's license number (of course, in compliance with any government regulations regarding the kind of information that can be obtained) “Division” may be thought of as a market location where the CATV system operates to deliver and support products from an operational perspective (i.e. customer care, marketing, sales). Authentication server 758 then authenticates user 702 as a valid subscriber and the user creates a new username and password for remote access to the online account. The user then re-logs-on to the portal of the CATV service provider, where a PC DVR control homepage is presented. It should be noted at this time that the aforementioned sequence assumes that the user has never set up his or her PC-based DVR control account. If such account had in fact already been set up, a link could be presented for wireless control sign up from the PC DVR control home page.
At this point, regardless of whether the user has previously registered for PC based DVR control, or has just registered for such control, the user can be prompted with an option to personalize the service (based on user's state, division, channel line-ups, DVR naming (in the case of multiple DVRs), and the like) If the user selects this personalization option, the application passes through IP core 724, through wireless DVR interface server 744, through to block 752, where personalized line-ups, etc, are stored. Following such personalization, a link can be presented at the PC DVR control page for wireless DVR control signup. When the user clicks such link, he or she will be presented with a new page with a list of steps needed to confirm wireless service and the type of wireless device to register for the remote DVR control service. Typical prompts could include entry of mobile phone number, entry of device manufacturer, and entry of device model. In one or more instances, with single-sign-on functionality, a user 702 who is already logged in over the Internet, as at 718, may simply click a single “Yes, set up my phone for DVR control” button. Authentication server 758 will then confirm the telephone number and device type. A Short Message Service (SMS) message is then sent to the user's mobile device, with a link included to download a DVR control client. Appropriate back-end intelligence may be included to ensure that the correct mobile client package is sent to the device, based on the parameters entered earlier during the just-described sign-up process.
In general terms, registration can include facilitating registration of a user 702 of the at least one digital video recorder 158 with a remote control service for the digital video recorders and facilitating the user downloading a digital video recorder remote control application to the remote wireless device 704, 706, 708. During registration, the user might rename one or more DVRs to particular given names, which might be persistently stored. The registration could include allocation of a user name and password, and storage of the user name and password could be facilitated for ease in verifying that the user is valid (a so-called “remember me” option). Further, registration of additional users of the DVR(s) 158 in home 716 can be facilitated. The additional users may be associated with the same account as the first user, and may also download the application to their remote devices (slightly different versions might be needed for different mobile devices). In some instances, the same user name and password may be shared across all users corresponding to the same account (as in a family structure). In other instances, authentication logic may be built so that multiple users within an account can have their own authentication factors.
One possible example of the aforementioned authentication process will now be provided. User 702 launches the mobile DVR application that has been downloaded as just described, and enters the username and password. The mobile DVR control application sends the username and password back to the authentication server 758 for validation (through wireless DVR interface server 744). Server 758 first authenticates the user information with block 712 (which can include appropriate IDS/IDM identity management functionality). Preferably, the mobile DVR control application supports username and password storage to avoid the need to continually re-enter the credentials during each log-on session. Server 758 then queries the billing system 710 to ensure that the customer is active.
Once all the user information has been authenticated, server 758 sends an acknowledgement back to the mobile DVR control application. Database 760 then maps the subscriber head-end, and the server 764 is queried for information regarding set top box 158, such as the MAC address. Channel line-ups from the head end can also be queried and returned to the authentication server 758. The mobile application can determine the last EPG retrieval instance; if the time is more than 24 hours (or some other predetermined value), an updated version of the EPG will be obtained. Similar logic and processes can be employed to deliver EPG listings for both PC-based and mobile DVR control. The channel lineup can be retrieved from database 760 as needed, and database 760 can be queried to retrieve, for example, IMS 5.0 data, available from Tribune Media Services.
One or more embodiments of the invention thus will allow subscriber's the ability to control their DVR-enabled Set Top Box (or set top box with separate associated DVR) to record their favorite TV programs from a remote location, including access via both PC and wireless platforms. Advantageously, the capabilities and features of the PC platform transcend across the wireless platform, with appropriate translation, via wireless DVR interface server 744. One or more embodiments of the remote DVR service advantageously offer consumers the ability to control their “time shifting” demands in a “place shifting” manner.
Many subscribers to CATV have multiple DVRs in their homes. Thus, the ability to deal with multiple DVRs remotely is preferably included in one or more inventive embodiments. In such cases, the modified representation of the menu includes an option to select between the at least one digital video recorder and at least a second digital video recorder, with an additional step of obtaining, from the remote wireless device, a representation of a selection of which DVR is desired. In some instances, responsive to the selection, a representation of a listing of selections already programmed on the selected digital video recorder is obtained from the back end, is translated into a modified representation fox the mobile wireless device, and transmission to the remote wireless device is facilitated.
Further, one or more embodiments of the inventive cross-platform DVR control advantageously provide PC-based and wireless-based versions with similar “look and feel” to the in-home version running on the user's DVR 158, yet with a mobile context in mind. As noted, in one or more embodiments, the wireless version will leverage both its user registration and/or authentication logic and back-end integration with its counterpart PC-based remote DVR solution. One advantage of this approach is the enablement of the same functional experience across the PC and wireless platforms.
Advantageously, the wireless version of the remote DVR application will be configured as a stand-alone application operable with both wireless scenarios 722 and 736. The stand-alone application may be made available across a mix of mobile handsets, by way of example and not limitation, LG 550, Sanyo 6600 Katana, Samsung M510, Nokia N95, Nokia N800, Windows Mobile phone, and the like. In one or more embodiments, the wireless application can be developed under different platforms, such as, by way of example and not limitation, JAVA, Symbian, and Windows Mobile.
One or more embodiments may be configured to provide basic functionality, such as single program recording, preferences, EPG integration, and program guide search. More enhanced DVR functionality may also be provided, such as series recording, conflict resolution, and a DVR show list Series recording can be in response to a command, from the remote wireless device, to record substantially all series episodes of a given television program (for example, for a given programming season). Conflict resolution can address conflicts between recording requests, and may involve offering appropriate guidance via the menu accessible to the user 702.
In one or more embodiments, a subscriber will have the ability to schedule a program recording from work using his/her PC, view and modify the previously initiated recording using his/her mobile phone while sitting in traffic, and once home, retrieve the recorded program and watch its content in the comfort of his/her home. The menu shown to the user may include a listing of selections already programmed on the home DVR(s) (a listing of selections may include information that no, one, or more selections are already programmed).
Additional exemplary details applicable to one or more embodiments of the invention will now be provided. The aforementioned remote DVR software applications should be available as a downloadable wireless client application, and be compatible with the various mobile handsets, DVRs, and so-on, which are present in the system. The user name and password should be user-selectable and, as noted, should be remembered in the handset application, so they only need to be entered upon initial setup. The application preferably supports 2-factor authentication (user name and password) for the mobile wireless handset (after the initial registration described above), ideally with user name and password storage on the handset (or other mobile device) in order to allow ease of use without requiting the user to enter 2-factor identification upon application launch. Advantageously, users may be prohibited from downloading the client to inappropriate handsets or other inappropriate mobile devices.
In one or more embodiments, the application is accessible through a menu of CATV operator-specific applications that is resident on the device, such as a CATV operator home page or portal. The application is preferably accessible through an icon on the home screen, and on the applications menu. The application may retrieve the most recent EPG data on, for example, a daily basis across all markets. In some instances, the application retrieves 72 hours of programming data for display on the EPG; however, 72 hours is a non-limiting example, and scaled-down data may be provided to mobile devices.
The application preferably supports a number of additional features, such as one or more of the following features discussed in this paragraph. One possible additional feature is the set up of default settings for 1-click recording. Another is user selection from more than one DVR, for accounts with multiple in-home DVRs. Yet another is user driven renaming of in-home DVRs for ease of use and logical DVR recognition. Still another is a central location for storage of renamed in-home DVRs, for DVR naming persistence across wireless and PC channels (persistent storage of logical renaming of in-home DVRs once applied by the user) A further additional feature is a timer on the handset (or other mobile device) in order to track the last time a user has launched his or her EPG data (this can be used to determine when a refresh of EPG data needs to be performed; in general terms, steps to be carried out can include monitoring, by the remote wireless device, of an amount of time since receipt of the electronic program listing, and, responsive to the monitoring, facilitating the remote wireless device obtaining a refresh of the electronic program listing). Still a further additional feature is the teal-time retrieval of information stored on DVR 158 in block 756, preferably via direct communication over network 140 via blocks 752 and 754, to block 748; this may be used, for example, to resolve scheduling conflicts in real time.
Additional information will now be provided regarding exemplary authentication and registration processes. The wireless application typically follows the online account registration process as per the PC-based solution. In one exemplary embodiment, the following data elements are required for online account registration: Master Account #, Last Name, First Name (of master account holder), State, Division, Last 4 digits of SSN, or Driver's License number. Regardless of whether the subscriber is registering for access to the PC-based or wireless-based Remote DVR application, the account registration process is preferably only required once in older to validate the user as a valid CATV subscriber. One or more of the following features are preferably also provided by the online service registration process:
One or more embodiments may implement one or more of the following post-registration requirements:
Appropriate functionality may also be provided to prompt a user to agree to appropriate terms of service before access is granted. In terms of account information, the application preferably leverages existing operations support systems (OSS) for customer information, such as DVR, sub account structure, customer EPG, and the like. OSS are computer systems (back-end systems) used by telecommunications service providers and the like, to provide functionality such as, by way of example and not limitation, network management, fault and alarm monitoring, provisioning, activation, and so on. Further; the application may be configured to perform one or mole of the following:
Further exemplary details will now be provided regarding the remote DVR user interface. The aforementioned application preferably supports a user interface, accessible through a standalone application, for mobile use, including proper resolution for optimal mobile screen usability. In order to interface with both PC and mobile wireless devices, the application must support a user interface that can be displayed in different resolutions based on device specifications. Preferably, the application supports an EPG's grid guide for the following:
Thus, the menu seen by a user 702 can preferably be configured to facilitate both vertical and horizontal navigation. The EPG should include the channel number, brand icon, channel name, program name, program description, air date, air time, duration, rating, and all other available metadata. When a program is highlighted on the EPG, the application should display the program name, program time, and program description on the same screen as the EPG. When a program is selected, the application must display the program name, program date, program time, and program description on a separate screen. Preferably, the application has the ability to, at a minimum, display one full hour (two half hour increments) by four channels of TV programming of the EPG on a single screen regardless of the device being used to access the remote DVR application.
In one or more embodiments, the application retrieves the same information database as the in-home EPG, and the EPG displays the channels and services that are available on the home STB/DVR. The user interface may advantageously be integrated with a customer's individual channel line-up, defined by the Service Zip Code The user interface should be integrated with the DVR access controls available through the server platform 768. The application should support scheduling of recordings through a one-click soft key button residing on the device, so as to initiate a recording using default settings (although in other embodiments, recording may require multiple clicks). When initiating a recording using the one-click soft key button, the application should schedule a recording according to the default setting parameters.
Still considering the remote DVR user interface, the application preferably enables another soft key button as an “Options”1 function, with the following selectable options: 1. Search, 2 Settings, 3. Back, 4 Exit. The application preferably supports the Search function which directs the user to a search screen. When on the search screen, the application should allow a user to select from a subset of search parameters for refined searches, and should allow a user to enter a key word search criteria. Once a search is initiated, the application should display the search results on the same search screen. Alternatively, the application may support two hard keys to function as Page Up and Page Down Search of a program listing could include, for example, a genre search, a date-time search, a text search, and/or a channel search. The menu seen by user 702 is preferably configured for at least one of alphabetical and chronological display of results of the search. Search functionality may be prominently displayed upon application launch, and may be optimized by allowing “shorthand” identifications of any of the terms to be searched on. Speech-to-text and text-to-speech functionality may be employed, to allow search parameter (or other) input via speech, with results (or other system responses) read out by speech synthesis.
The application preferably supports the Settings function which directs the user to a settings screen, and should display preference options on a separate screen. Examples of preference options include: Recording Frequency, Save Until, Start Recording, Stop Recording The application should display changes to an individual preference option on a separate screen, and should allow the user to save the selected Setting preferences as the default settings for all future recordings.
The Back selection should be visible and active when the user is in the Options menu. This selection should serve to close out of the Options menu when pressed and return the user to the EPG screen. The Exit selection should function as a means to exit from the application. When selected, it should result in closing out of the application. The Back button physically located on the device should result in returning the user to the previously selected function.
The application should provide the option to navigate horizontally across program listings by using right and left soft keys in order to navigate across programs and program times. When navigating horizontally, the application must not allow a user to navigate to a program time prior to the current time. The application should provide the option to navigate vertically across program listings using one of the following methods:
When navigating vertically, the application should allow continual looping of the complete list of channels/programs once a user has scrolled beyond the last channel/program available on the EPG. The application should support quick channel navigation by entering channel numbers using the mobile handset's number pad. The application can display a separate view which lists all available Set Top Boxes, if a user has more than one Set lop Box available with in-home DVR capability. This should only appear for users who have multiple STBs with DVR capability set up under their account. If a user has multiple in-home DVRs, the application should allow a user to select one of the DVRs associated to the account as the default DVR for scheduling recordings remotely. The application can allow the end user to select one or multiple STB/DVRs to record a specified program, and should support renaming of STB/DVRs driven by the end user.
The STB/DVR renaming option should be prompted upon initial application launch, and an already active PC-based Remote DVR user should be able to retrieve the STB/DVR previously renamed through their wireless application. The application should allow the renamed STB/DVR to be retrieved from a centralized location for use on the handset. Upon subsequent recordings, the application should retrieve and display user preferred STB/DVR name, and upon subsequent recordings scheduled through the application, user should no longer be prompted to rename the STB/DVR The application should support the ability to rename an STB under a preference option, to be initiated by the user at any time, should display a confirmation message in a separate view for the renaming of an STB/DVR, and should allow a user to navigate out of the confirmation notification for recording.
Further exemplary details will now be provided regarding recording functionality. The application must be able to process a recording request real-time, and to record a program up to a predetermined amount of time, such as 72 hours, ahead of the current date. The application should support recording parameters to be saved on one or mole DVRs, and should support multiple DVR recording. For households with multiple DVRs, users must have the ability to select one of many DVRs when scheduling a recording request. The application must support applying the same DVR settings across all DVRs accessed remotely from a single account.
The application must allow a user to select his/her Recording Frequency setting, from the following options: single, series further, the application must allow the user to set/change the Save Until setting to any of the following preferences: space is needed, I delete. The application must allow the user to set and/or change the Start Recording setting to, for example, any of the following preferences: On time, 1 minute early, 2 minutes early, 3 minutes early, 4 minutes early, 5 minutes early, 15 minutes early, 30 minutes early, 1 minute late, 2 minutes late, 3 minutes late, 4 minutes late, 5 minutes late, 15 minutes late. Yet further, the application must allow the user to set and/or change the Stop Recording setting to any of the following preferences: On time, 1 minute earlier, 2 minutes earlier, 3 minutes earlier, 4 minutes earlier, 5 minutes earlier, 15 minutes earlier, 30 minutes earlier, 1 minute late, 2 minutes late, 3 minutes late, 4 minutes late, 5 minutes late, 15 minutes late, 1 hour late, 2 hours late.
Preferably, the application displays a visual indicator on the EPG that a recording is scheduled. This should typically only apply for program(s) which have only been scheduled remotely (PC or wireless). The application must be able to schedule a recording for a single program based on the user's program selection on the EPG, and must also be able to schedule a recording for a series program based on the user's program selection on the EPG. The application preferably allows a user to initiate a recording request through a one-click option on the grid guide. The application preferably allows a user to initiate a recording request from a separate screen where the program name, program description, start time, and program duration are displayed.
In one or more embodiments, the application must allow a user to initiate a recording request anytime prior the program's end time, and must prevent a user from initiating a recording request that has a program start time earlier than the current time. The application should support a single recording set up parameter.
In another aspect, recording confirmation capability is provided. Thus, the application should send a confirmation of a scheduled recording immediately following a user's selection to record a program, and the application should notify a user if a recording request could not be fulfilled. Further, the application should provide the end user with an optional confirmation that the recording has been successfully scheduled via a text message, SMS, or multimedia messaging service (MMS) to a wireless device, after inputting a 10 digit cellular telephone number and wireless carrier. Such an indication is preferably optional for the user to receive.
In one or more embodiments, conflict management capability may be provided.
Further details will now be provided regarding electronic program integration and search capabilities. Preferably, the EPG for the emote control application uses the same information database as the STB 158. The EPG that is retrieved should be specific to an individual subscriber's channel line-up, should provide channel name and number, show name, air date, air time, duration, rating, and all other available metadata. The application should allow the EPG to display a recording indicator on any programs which were already set to “record.” This includes programs which were set to record either at home or through an end user's PC. The application must support searches by program title (all metadata), by channel name (all metadata), and by theme (all metadata). The application should support one or more of the following theme selections: News & Weather, Sports, Kids, HDTV, and the like.
Further, the application should support filters/searches by Date and Time for ease of navigation, and should require both Date and Time filter parameters when on the Search screen. In one or more embodiments, the ability to display Date parameters which fall only within 72 hours (or some other appropriate period) of the current date and time is supported. The application should display search results on a separate screen similar to the search results display view at home, and at a minimum, the application should display the following information on the search results view: Program Title, Start Time. In some instances, the application supports user search results to set up single recording, and the search results screen may include a one-click soft key button to initiate recording.
In one or more embodiments, applications accessed by PC or by wireless devices may have a similar look and feel. Advantageously, the same server(s) can be used for both the Internet-based solution 718 and the wireless solutions 722, 736, but different clients may be employed.
In another aspect, a method for controlling at least one digital video recorder includes the steps of querying at least one server from a wireless device 704, 706, 708 to obtain a DVR identifier and DVR control preference information, receiving the DVR identifier and DVR control preference information from the server, displaying the DVR identifier on the wireless device, and controlling the at least one digital video recorder 158 based on the DVR control preference information by selecting the DVR identifier displayed on the wireless device. The DVR identifier can be, for example, a MAC address, a personalized label, and/or a graphical representation. The DVR control preference information can include, for example, one or more of default setting storage requirements; color information; recording parameters; conflict resolution parameters; parental control settings; reminder information; alert information; and the like.
A number of exemplary, non-limiting use cases will now be set forth, to illustrate how one or more embodiments of the invention may be advantageously employed. Initially, some definitions will be presented:
DVR and Wireless subscriber (Joe) has one DVR in his home. Toe has broadband access to the Internet from his PC at work.
CATV DVR and Wireless subscriber (Nancy) has a multiple DVRs in her home
DVR and Wireless subscriber (Bob) just signed up for a new DVR box and now has multiple DVRs in his home. Bob has already registered for remote DVR access. This is the first time Bob is accessing his DVR. He has broadband access to the Internet from his PC at work.
DVR and wireless subscriber Sue and her son Dave have registered for the Remote DVR service for use on their respective mobile phones and PCs. There are two DVRs under this single account. Neither of these DVRs has been renamed. Both have broadband access to the Internet from their PCs at work and/or home.
DVR and wireless subscriber Amy has registered for the Remote DVR service for use on her mobile phone. There is one DVR under this account. Amy is accessing her DVR application while on a train
Nancy is a valid CATV subscriber who has forgotten her password for the Remote DVR Control application, and has requested a password reset online.
Tom will be able to set, store, and change user preferences on both the mobile handset DVR Control application, and on the PC DVR Control portal. In addition, Tom will be able to override preferences originally stored on the PC while using the handset application, or vice-versa. In this case, Tom would like to override a preference storing a recording start time, and personalize the name of a DVR box stored in his room
In one or more embodiments, the DVR Control system will allow series recording functionality; however a scheduled series recording which conflicts with a previously set series recording (set on PC) will result in a recording functionality error displayed to the user.
The DVR Control system will allow up to two simultaneous recordings. However, there will be instances where a user will attempt to record a third recording unknowingly. In this scenario, a failed recording request will result in an error message displayed to the user. Tom will attempt to set a program recording in addition to 2 previous set recordings—with all 3 programs occurring or having overlapping tithe slots.
CATV DVR and wireless subscriber Rich has already registered for the Remote DVR service for use on his mobile phone
10. Rich is then taken to his home guide on the channel number and time slot of the baseball game he has just set to record. He enters channel number 4 and is taken directly to this channel on his guide.
CATV DVR and Wireless subscriber (foe) has one DVR in his home and two wireless lines associated with his account, one for himself and one for his wife Natalie. Joe has already registered online for his Remote DVR account Joe has broadband access to the Internet from his PC at work.
Video/DVR subscriber (Joe) has one DVR in his home. Joe has broadband access to the Internet from his PC at work
Video/DVR subscriber (Gordon) has three DVRs in his home. Gordon has broadband access to the Internet from his PC at work
Video/DVR subscriber (Sally) has one DVR in her home. Sally has broadband access to the Internet from her PC at work
Video/DVR subscriber (Lucy) has one DVR in her home. Lucy has a mobile phone with a Remote DVR Application.
Video/DVR subscriber (Alex) has one DVR in his home. Alex has broadband access to the Internet from his PC at work
The invention can employ hardware and/or software aspects. Software includes but is not limited to firmware, resident software, microcode, etc. An exemplary embodiment of an inventive apparatus can include a memory and at least one processor coupled to the memory. The processor can be operative to facilitate performance of one or more of the method steps described herein. In another aspect, the apparatus can comprise means for performing the various method steps. The means can include one or more hardware modules, one or more software modules, or a mixture of one or more software modules and one or more hardware modules (appropriate interconnections via bus, network, and the like can also be included). One or more method steps of the present invention can be implemented in the form of an article of manufacture comprising a machine readable medium that contains one or more programs that when executed implement such step or steps.
As is known in the art, part or all of one or more aspects of the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a computer readable medium having computer readable code means embodied thereon. The computer readable program code means is operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein. The computer readable medium may be a recordable medium (e.g., floppy disks, hard drives, compact disks, EEPROMs, or memory cards) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used. The computer-readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic media or height variations on the surface of a compact disk.
The computer systems and servers described herein each contain a memory that will configure associated processors to implement the methods, steps, and functions disclosed herein. Such methods, steps, and functions can be carried out, e.g., by processing capability on individual elements in the other figures, or by any combination thereof. The memories could be distributed or local and the processors could be distributed or singular. The memories could be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices. Moreover, the term “memory” should be construed broadly enough to encompass any information able to be read from or written to an address in the addressable space accessed by an associated processor. With this definition, information on a network is still within a memory because the associated processor can retrieve the information from the network.
Thus, elements of one or more embodiments of the present invention can make use of computer technology with appropriate instructions to implement method steps described herein.
Accordingly, it will be appreciated that one or more embodiments of the present invention can include a computer program comprising computer program code means adapted to perform one or all of the steps of any methods or claims set forth herein when such program is run on a computer, and that such program may be embodied on a computer readable medium. Further, one or more embodiments of the present invention can include a computer comprising code adapted to cause the computer to carry out one or more steps of methods or claims set forth herein, together with one or more apparatus elements or features as depicted and described herein.
Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made by one skilled in the art without departing from the scope or spirit of the invention