HK1105149B - Method of sharing personal media using a digital recorder - Google Patents

Description

Method for sharing personal media by digital video recorder

Technical Field

The present invention relates to personal multimedia services. More particularly, the present invention relates to a method and apparatus for sharing personal media using a digital video recorder.

Background

With the advent of Video Cassette Recorders (VCRs), television viewers have recorded television program events (events) that are played back within a given time period and played back the recorded program content at a later time. During recording, a VCR converts electrical signals of program content into magnetic signals and stores the magnetic signals on magnetic tape. During playback, the video recorder converts the magnetic signals into electrical signals, and the associated television displays the program content of the signals on its screen.

With the development of digital technology, VCRs have been replaced by Digital Video Recorders (DVRs). Like a VCR, a DVR also functions to record the program content for playback for later playback. During recording, the digital video recorder DVR converts the electrical signals of the broadcast program content into digital information, for example an MPEG data stream, which is then stored in a storage device, or stores the television signals, which have been digitized beforehand, directly in a memory. During playback, the DVR converts the digital signal back to an analog signal. The connected television set displays the program content in the signal on its screen.

When recording television program content with a VCR, the user must manually select the channel and control the VCR, or ask someone else to do the operation. When using a DVR, a user may establish a program recording sequence by programming the DVR according to a television program guide, thereby causing the recording process to be performed automatically.

While DVRs allow users to specify the recording time, channel, and duration of multiple events, they have not met the ever-increasing need to determine and obtain program content in a more intelligent manner. For example, when a user is away from a DVR and a television, his DVR may not be programmed to record events of programs that he likes.

It is desirable to establish a communication system through which users can access and program their DVRs at any location to a centralized tv program guide database.

Such systems may also enable users to transfer recorded program material from one DVR to another DVR, or from a server to a DVR, in a secure manner that protects the copyrights of the program material provider.

Drawings

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIG. 1 is a block diagram illustrating a communication system for remote access to a centralized personal television service (centralized personal television service);

FIG. 2 is a data flow diagram illustrating the operation of the system shown in FIG. 1;

FIG. 3 is a diagram showing the structure of the user database and the event database shown in FIG. 2;

FIG. 4 is a flow chart illustrating a process by which a personal TV service web server obtains remote program instructions from a user;

FIG. 5 is a schematic diagram of a graphical user interface for program selection;

FIG. 6 is a screen shot of a Now browsing web page appearing on a user's web browser or television screen;

FIG. 7 is a block diagram illustrating interaction between a personal television service center, a DVR, and an external content server over the Internet;

FIG. 8 is a screen shot showing a playback bar indicating that the content download speed is faster than the playback speed;

FIG. 9 is a diagram showing a digital certificate containing information for a DVR;

FIG. 10 is a block diagram showing a media server in a local area network connected to a DVR in a home;

FIG. 11 is a block diagram that illustrates the communication exchange between two DVRs for generating a strong encrypted connection;

FIG. 12 is a diagram showing a digital certificate containing information for a DVR and a content server;

FIG. 13 is a block diagram showing a server recording DVR access information for billing;

FIG. 14 is a block diagram showing a domain name redirector (DOMAIN NAME redirector) forwarding a DVR's request to a third party server;

FIG. 15 is a block diagram that illustrates an encryption pipeline for a DVR to act as a third party content server;

FIG. 16 is a screen shot Showing a Now watching screen accessible to a media server;

FIG. 17 is a screen shot of a content screen displaying content accessible to a media server;

FIG. 18 is a screen shot of a transfer options screen displaying content from a media server;

FIG. 19 is a screen shot of a program status screen showing a program being transmitted from the media server;

FIG. 20 is a screen shot of a music screen displaying music accessible from a media server;

FIG. 21 is a screen shot of an image screen displaying images accessible from a media server;

FIG. 22 shows a block diagram of a media server in a local area network connected to a DVR in a home, the media server having access to the Internet; and

fig. 23 shows a block diagram of a media server in a local area network connected to a home DVR, both of which have access to the internet.

Detailed Description

Described herein is a method and apparatus for sharing personal media using a digital video recorder. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It may be evident, however, that such specific details are not required to practice the present invention. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

In the discussion that follows, with respect to the figures, like reference numerals refer to like parts throughout the various views.

A. System for remote access to personal television services

Referring to fig. 1, a communication system for remote access to personal television services is shown and generally designated 100. According to one approach, a Digital Video Recorder (DVR)110 installed in a home communicates with a personal television service center (hereinafter referred to as a service center) 130, and the service center 130 provides program guide data, graphical resources (e.g., fonts, images, etc.), service information, and other forms of data that enable the DVR110 to operate independently of the service center 130 to satisfy viewer interest. The function of a DVR is represented by U.S. patent No. 6,233,389, owned by the applicant and incorporated herein by reference. The communication system uses a secure distributed architecture to transfer data between the DVR110 and the service center 130 to protect service data and user privacy. DVR110 receives a broadcast signal from antenna 115 or a television signal from a cable television system.

In one embodiment of the invention, DVR110 generally comprises: a plurality of components necessary for digitizing the analog television signal and converting it into a digital data stream; a plurality of components designed for recording a plurality of segments of said data stream; a plurality of storage devices configured to retain a plurality of segments of the data stream; a plurality of components designed to acquire a plurality of segments of the data stream, convert the data stream into an analog signal, then modulate the signal onto an RF carrier, and transmit the signal to standard television 120 via the RF carrier signal; and an interface 125 through which DVR110 communicates with network 140.

DVR110 includes a local secure cryptographic chip that contains a non-changeable private key. The security function of DVR110 is further described in U.S. patent No. 6,385,739, which is owned by the applicant and incorporated herein by reference.

The DVR110 may connect directly to the service center 130 through its internal telephone modem call-in modem pool (originating call modem bank) 145. The incoming call is first routed to the service center 130 for identification verification. Once authenticated, the incoming call is authorized. A private modem pool (private modem bank)145 replies to the incoming call and the DVR110 is then granted access to the database in the server center 130.

Alternatively, DVR110 may be indirectly connected to service center 130 through network 140. Interface 125 between DVR110 and network 140 may be an internal telephone modem of DVR110, or a dedicated network interface such as a cable modem. The computer network 140 may be either a private network or the internet. DVR110 initiates a connection to computer network 140 by dialing an Internet Service Provider (ISP) local access telephone number. The ISP directs the network connection request to the service center 130 for identification verification. Upon verification, the network connection is authorized and DVR110 is then granted access to the database in service center 130.

The service center 130 receives program schedule information 150 from an external source. The program schedule information 150 forms the basis of a program guide that a television viewer uses to select television programs for recording. The service center 130 communicates with a computer network 140 through an interface 135.

A television viewer may remotely access a program database in the service center 130 by establishing a channel with the service center 130 over the computer network 140 using a remote computer 155 or a personal digital assistant 160.

Referring to fig. 2, the service center 130 includes: a web server 200 for collecting, organizing and providing program schedule information; a program database 210 for storing program schedule information; a user database 220 for storing information of users and the digital video recorder; an event database 230 for storing an event table for each user; and a scheduler 240 for traversing the user database and retrieving the event table from the event database. Service center 130 may also include a network interface through which a network server communicates with DVRs.

In one embodiment, DVR110 comprises: mini server 250 for controlling communication between DVR110 and service center 130; a local program storage guide 260 for recording the program guide provided by the service center 130 and updated whenever the DVR110 accesses the service center 130; an event queue 270, which is a data structure used to initiate a recording session to capture a selected television program; a Pseudo Random Number Generator (PRNG)280 for generating a remote access authorization key (authorization key); there is also a network interface 125 for connecting DVR110 to computer network 140. The event queue 270 is connected to a recording device that forms part of the DVR 110.

Remote computer 155 and Personal Digital Assistant (PDA)160 each include a web browser 290, which may be a conventional web browser that enables a user to browse web pages.

Fig. 3 is a diagram showing the structures of the user database 220 and the event database 230. The user database 220 includes a plurality of user records 300. Each user record 300 includes a number of fields, among which a user identification 310, a key 320, a DVR identification 330, and an event table pointer 340. The user identification field 310 serves as a key to access the user database 220. Key field 320 is used to store an authorization key from a user attempting to remotely program their DVR. The DVR identity 330 is used to store the web address and connection details needed to establish a channel with the DVR 110.

In the user database 220, a separate event table 350 is maintained for each user. The event table 350 is stored in the event database 230. Each event table 350 includes a plurality of event records 360. Each event record includes a plurality of fields, including a time field 370, a channel field 380, and a duration field 390. Time field 370 is used to indicate the start time of the recording, which includes the date and time of the program event. The channel field 380 specifies which channel the DVR should record. Duration field 390 is used to specify how long the DVR should record the program content. The event record may also include an identifier of the record (or target) in the program guide database. The DVR retrieves the desired information from the program guide database.

B. Program for remote access to personal television services

FIG. 2, in conjunction with FIG. 1, illustrates various programs that collectively implement the functionality of the techniques described herein.

The service center 130 periodically receives program schedule information 150 from an external source. Once the program schedule information 150 arrives, the program database 210 is updated accordingly.

DVR110 periodically updates its local program guide 260 by reading a web page from web server 200 or by cable, satellite, or telephone. In response to a request from DVR110, web server 200 first consults program database 210 to obtain updated program information and then dynamically builds a web page that includes the updated program schedule information.

There are two remote access modes available: direct and indirect. A television viewer may program DVR110 indirectly by using remote computer 155 or web browser 290 on personal digital assistant 160. In this case, the web browser 290 is used to access a specific website resident on the web server 200. The web server 200 presents the program guide to the television viewer using a graphical user interface as shown in fig. 5. The television viewer selects a television program by program title and time slot to indicate the program that DVR110 should record.

The service center 130 periodically executes a dispatch process 240. Scheduler 240 traverses user database 220. The scheduler 240 retrieves the event table 350 from the event database 230 whenever the scheduler 240 encounters a user specifying a program event. Scheduler 240 then establishes a channel with mini-server 250 inside DVR 110. This channel is designed to allow scheduler 240 to retrieve a particular event scheduling web page from mini server 250. Microserver 250 sends an event scheduling web page to scheduler 240. Scheduler 240 then completes the event scheduling web page and submits it back to mini server 250.

Microserver 250 may also cause dispatcher 240 to initiate event transmission by polling dispatcher 240 for events.

Mini server 250 updates an event queue 270 that forms part of DVR110 with the event instructions found in the event scheduling web page. Event queue 270 is a data structure that DVR110 uses to initiate a recording session to capture a selected television program.

To authenticate a transaction, web server 200 includes one or more authorization codes for a user to contact DVR110 to program the DVR. DVR110 compares the authorization code to the private copy stored in its persistent storage. The authorization code has timeliness and can be set to be expired and expired according to the system security requirement instruction.

Using the direct remote access feature, the user must first obtain an authorization key from the DVR110, which is generated by a pseudo-random number generator (PRNG) 280. The user communicates directly with the DVR110 through a television at the DVR. DVR110 submits the authorization key to the user. The user then accesses DVR110 through the Internet using their computer 155 or their personal digital assistant PDA 160. The user submits the authorization key and instructs DVR110 through a graphical user interface managed by mini server 250. Also, once the user accesses it in a direct manner, the user may download the program to DVR 110.

C. Program for acquiring remote programming instructions

FIG. 4 is a flowchart showing a process used by web server 200 and mini-server 250 to obtain remote programming instructions from a user. Both are shown in parallel, but are independent programs in normal use. The procedure comprises the following steps:

step 400: web server 200 or mini server 250 presents an authorization request form to a user accessing a specific website managed by web server 200 or mini server 250 on a first web page;

step 410: the network server 200 receives an authorized password input by a user; mini server 250 receives an authorization key from the user;

step 420: the web server verifies the authorization password with the user database 220; mini server 250 verifies the authorization key using its stored key.

Step 430: once web server 200 has verified the authorized password in user database 220, it will write a Cookie (a short piece of information) in the permanent memory of remote computer 155 or personal digital assistant 160; once mini-server 250 has verified the authorization key, it will write a Cookie in the permanent memory of remote computer 155 or PDA 160;

step 440: after the user is identified and authenticated, web server 200 or mini server 250 presents a program guide to the user;

step 450: the web server 200 receives the user's selection and creates a unique event table 350 for the user. The table of contents 350 is stored in the event database 230. The mini-server 200 receives the user's selection and places it on the event queue 270.

In step 440, web server 200 or microserver 250 follows the necessary scripts for the first web site submitted to the user and searches for valid Cookie segments on remote computer 155 or personal digital assistant 160. Once a valid Cookie is found, steps 400 through 430 are excluded from the program flow.

D. Graphical user interface for program selection

Fig. 5 is an illustration of an exemplary Graphical User Interface (GUI)500 for program selection. GUI 500 is used both on the front panel of the DVR and is incorporated into a web page that is submitted to a remote user by web server 200. When executed directly on DVR110, GUI 500 is directly manipulated by a control program in DVR 110. When GUI 500 is presented to a remote user over a computer network, it is embodied as an active server web page. FIG. 6 is a screen shot of a Now browsing web page in a user's web browser.

The GUI 500 includes a table 505 that contains a plurality of columns 510 and a plurality of rows 515. Column 510 corresponds to days of a week (and a particular calendar date). Row 515 corresponds to the hours of a given day. The columns 510 and rows 515 in the table 505 are actually formed by data selection controls (controls) whose titles are set to indicate the titles of television programs whose broadcast time periods are determined according to the positions of the controls in the table 505. The GUI further includes: a mechanism (mechanism) for scrolling up 520 and scrolling down 525; a mechanism for paging forward 530 and paging backward 535; a mechanism for selecting a particular television program; a mechanism for creating a program event table 350, the mechanism comprising a selected television program; and a mechanism for editing the event table 350. In addition, it may include a mechanism for controlling the downloading; a mechanism to indicate that a download is in progress; and a mechanism for cancelling the program being downloaded.

The position of the widget corresponds to the day and hour of the television program content event. The user may toggle the selection control displayed in GUI 500. When GUI 500 is returned to web server 200, event table 350 is created for the user with the identifier of the selected control along with program guide 260. Subsequently, the event table 350 is stored in the event database 230 in case of remote programming. For locally programmed DVRs 110, the event table 350 is stored directly in the event queue 270 that controls the DVR's recording sequence.

E. Accessing digital video recorders over the internet

Fig. 7 is a block diagram of a general schema (700) illustrating the interaction between the service center 130, the DVR110, and the external content server 720 via the internet, wherein a particular internet access modality is integrated into the DVR enabling it to obtain a particular type of content via the internet connection 140 and enable it to be displayed on a nowwatching web page as shown in fig. 6. For clarity of illustration of the example, fig. 7 and the description herein refer to specific elements and protocols that may be used in the implementation, such as internet, Linux, DHCP, etc. However, other functionally similar elements or protocols may be used in alternative implementations. For example, the download may occur over any public, private, or private network, rather than over the internet. Other operating systems and dynamic address protocols may also be used.

In the Now browsing page, an enumeration of content names (i.e., titles of television programs) indicates that such content is fetched onto the GUI 500; and a record icon, or some other form thereof, indicating that the download process is in progress. The viewer can pick up the content (i.e., the television program) and can play it at any time.

The download may be at any speed. Thus, the interface 125 in fig. 1 does not have any dependency on the download speed. Fig. 8 is a screen shot of a web page showing a playback bar 801, matched by growing a green field 802 to indicate that the content is downloaded faster than the playback speed 803. Devices other than such a playback bar 801 may also be used to indicate that the content download speed is faster than the playback speed. In any case, the viewer may use various special effects actions (click-play actions) on any amount of content downloaded to that point.

The fact that content is downloaded over the internet is apparent to the viewer, and there are many ways to indicate that the content is from the internet other than in the context of providing program information.

Pointers to downloaded content are stored in the local content database 740 on the hard drive of the video recorder 110 in a similar manner to the storage of broadcast programs so that searching and outputting all forms can display those programs appropriately and provide operations.

In a channel or network-oriented scenario, downloadable programs are displayed in a manner similar to broadcast programs. These contexts may need to be modified in order to have the channel or network "program (lineup)" appear in a reasonable way, since the time and location of such programs are irrelevant.

The sequence numbers of available content items in the Now browsing environment as shown in fig. 6 may make navigation inconvenient. Although not required at initial execution, the environment may be modified to make navigation of many items easier.

The entity that provides content from some servers may be considered a television network. Each unique server name indicates a channel. Here, "server" is simply a name on the network; it can map any physical server anywhere in the world.

Once server 720 is connected, DVR110 requests media content based on the specified program identification. This is mapped by the web server 200 to a particular content and then transmitted over the connection. Either the content server or the DVR may adjust the download speed.

If the viewer requests multiple downloads, then DVR110 may select a number of different methods to obtain the content; it may maximize the number of connections initiated or requests queued, or both.

In one approach, the elements in FIG. 7 focus on the security of the DVR. Opening a network port may result in a significant security gap around copyrighted content and protecting user private data issues.

In one embodiment, this protection is managed using a standard Linux firewall by automatically blocking access to bi-directional communication to all but a few well-known ports (e.g., web (http) or discovery). The DVR's application software utilizes a well-known port to connect to an external content server 720 to download the media content.

DVR110 has a means for dynamically addressing client software, such as Linux DHCP client software. Upon importing a DVR, the DHCP client software uses the well-known port to obtain a network address for the DVR from the dynamic address source if a network interface is detected. For example, the DHCP client software of DVR110 detects external DHCP server 750 using the DHCP protocol. If no server can be found, the network will be disabled. Otherwise, DVR110 will initialize the network parameters from the DHCP response.

One problem with such Linux firewalls is that the external DHCP server 750 is required to configure internet access information. It is well known that there are many ways to read data or to divert a stream (stream) between two devices on the internet. One possibility is a spoofing attack (leveraging), in which a malicious DHCP server configures network access information in such a way that a malicious host logs in to a DVR with a false server address and attacks the DVR.

To defeat such an attack, in one embodiment, all communications with content server 720 are authenticated and encrypted. Content server 720 has access to the public key of DVR110 and the DVR also has a copy of the public key of content server 720. DVR110 has metadata content information about content server 720 downloaded by service center 130. DVR110 stores the metadata in its database 740 and operates on the data in database 740. With the certificate exchange, DVR110 and content server 720 generate a one-time session key, with which all further communications are encrypted. In one embodiment, the Blowfish algorithm is used for encrypted session communications. The public key of content server 720 is distributed from service center 130, which also provides the appropriate program guide reference for content server 720.

The service center 130 receives the specification of the content server 720. In one embodiment, such instructions include a URL of the server, content instructions, content identification, "channel" instructions, "network" instructions, and the like. These data are entered into the content server's specification (CSD) database 710. While providing a set of public keys for accessing service center 720.

In order for content server 720 to accept a connection from DVR110, it must be able to access the public key of a particular DVR. The distribution of the keys may be synchronized or by a pre-shared key distribution method. In synchronous distributed keying, content server 720 establishes an authenticated connection with service center 130, provides the DVR serial number, and requests service center 130 to provide the associated public key. After obtaining the DVR serial number, the service center 130 returns an associated public key. Content server 720 may quickly store the public key. Each key has an expiration date indicating when the content server 720 must delete the key. The service center 130 may keep a log of all assigned public keys, for example, for auditing key assignments.

Service center 130 may deny the key for DVRs that are providing an inactive state. In addition, content server 720 may respond to requests from service center 130 for key revocation, for example, if a particular DVR becomes inactive.

Media recorder 730 is a subsystem of the personal television services application software of DVR 110. The media recorder 730 allows for the synchronized recording and playback of downloaded content. The recorded content is stored in content database 740 of DVR 110. Without a permanent network connection, the media recorder 730 would not be able to start. In one execution, the media recorder 730 includes a number of different threads.

(1) Recording a queue thread: the thread manages the network download request queue and implements the download policy. Initially, this could be a simple FIFO queue held in a database. Once the download policy is enforced, the recording queue policy object is retained.

(2) Acquiring a recording thread: the thread is responsible for managing the connection with the content server 720. The acquisition recording thread connects to the server, executes the authentication protocol, requests the required content, and manages the content download.

As a variation of this policy, a personal television service application or program object in the media recorder 730 may instruct multiple servers to accept queries for media content. Inquiring a server according to the sequence of acquiring the recording threads; the first server to accept the download request is used. This provides load balancing of content requests with multiple content servers in a group of servers or data center.

The get recording thread periodically stores or checks its status to a database in DVR 110. This check allows the download to be restarted from the point where the error occurred in the multimedia content when a power outage or system error occurred while the download was in progress. The get recording thread also manages the state of the database object for display or navigation of the content being downloaded. For example, the acquisition recording thread manages the state of the recording object normally displayed in the Now viewing environment as shown in fig. 6. It is possible that at any point in time there are one or more such threads in an active state.

DVR-to-DVR interaction

In one approach, an apparatus is provided for transferring media and database units between two DVRs. Referring to fig. 7, an example of a transfer is shown, such as using a disk storage of a small capacity provided by portable DVR 760. For example, a user may transfer desired media and non-visible related service data to portable DVR 760 before going on vacation and then carry portable DVR 760 around to make the media available at any time. Another example of a transmission is shown using two DVRs, DVR110 and DVR770, automatically controlled with respect to each other to allow the two media streams to be played in exact synchronization to achieve the same way of operation.

There are many ways to connect two DVRs. In one embodiment, the output of the source DVR110 is connected to the input of the destination DVR 770. While this approach works, it fails to deliver metadata information about the media stream that is critical to viewer satisfaction with managing and using the media stream.

The media stream stored in DVR110 includes the media content itself; and a database object that provides descriptive information about the media content. If a data transfer method is used, such as a network (e.g., IEEE 802.3) or a direct connection (e.g., IEEE 1394), both media content and descriptive information may be transferred to maintain the integrity of the user experience.

Content owners are concerned with potential theft of their content. Further methods for encrypting data transmissions between DVRs 110 and 770 may be performed in many standard and conventional ways. For example, the transmission may be encrypted using a Diffie-Hellman secure connection protocol to generate a one-time key.

An integrated security system may be used if it is desired to have transmissions only between certain DVRs. The public key of each DVR is known to the other party through a pre-shared key or dynamic exchange of keys. When transmission starts, the DVRs exchange a signed certificate encrypted based on the public key of the other DVR. If both DVRs are able to decrypt and verify the signature of the other party, then each DVR verifies the identity of the other party and generates a one-time session key for encryption during transmission.

The key distribution in this case may be performed by the service center 130. The viewer may connect to the service center 130 and request authorization of his two DVRs 110 and 770 for data transfer between the two. The service center 130 sends an authorization object containing the public key of each DVR to the other DVR via an appropriate download device. Service center 130 maintains the operational record for later review, including information that authenticates each DVR. For example, if the security system of one DVR is breached, resulting in the public keys of other DVRs being exposed, the other DVRs are likely to be modified, making them appear to have been authorized to login to the source DVR 110. Each DVR maintains a record of the transmissions. The record is uploaded to the service center 130. This information can later be processed to seek infringement of copy protection and copies transferred to unauthorized DVRs, and so on.

If the transmission is interrupted, the destination DVR770 identifies the media stream as "partial" in the described object. Later, the transmission may be restarted. Because the design of the database system ensures that the media stream can be uniquely identified in the destination DVR770, part of the media stream is found and transmitted from its end, thus avoiding the retransmission of already stored media. Once the entire media stream is stored, the described objects are updated to show the entire media stream.

Digital data may be transmitted between DVRs at any suitable speed. For example, it is possible that the network between DVRs is slow, in which case the transmission duration may be longer than the time to play back the content. Alternatively, the network may be fast, in which case the transmission time of the multiple media streams may be much less than the playback time of one content item. The user at the destination DVR end can watch the media stream immediately after the first part is downloaded, and can continue to download the media stream.

It is not required that the source or destination DVR be a full DVR. For example, a media stream stored on a server at the head end of the line may be reliably transmitted to the destination DVR 770. Alternatively, the media stream stored on the source DVR110 may be transmitted to the head-end server.

For example, the PC may use a USB adapter on the DVR that contains an encryption chip. The PC establishes a security mechanism for transferring content to and from the PC. To other DVRs, the PC may appear to be a DVR because it uses a USB adapter to authenticate and generate encrypted keys. The content may then be stored on the PC in encrypted form. The content may be e-mailed to other PCs or DVRs. Other PCs must have a USB adapter to decrypt the content. The certificate passed from the service center 130 is stored in NVRAM on the USB adapter, so the certificate is moved with the adapter instead of being stored on the PC's hard drive.

Some media distribution architectures, such as digital satellite systems, broadcast most of the media content in an encrypted state. Using a smart card based local decryption facility, media content can only be decrypted when viewed, thus protecting the content from theft. The DVR may save these encrypted media streams to disk and initiate decryption operations at playback. The method may be used to transfer media content between two DVRs. To fully comply with a particular set of content protection regulations associated with a media stream (e.g., playable only once, expired after a day, etc.), a DVR maintains copy protection information associated with the media stream (including whether the media stream is stored in an encrypted manner) along with a database object that specifies the media stream.

The content protection provisions associated with the media stream may also be transmitted to the destination DVR 770. for example, DVR110 may have stored a movie from content server 720, and the movie is not decrypted until it is viewed. If the viewer wishes to transmit the media stream, it is copied to the media area of the destination DVR770 while the description object is also transmitted. In this manner, the original information in the media stream is faithfully copied into the destination DVR 770.

The smart card may be unplugged from the source DVR110 and installed onto the destination DVR 770. When media content is viewed, the viewer is charged appropriately and complies with all copy protection regulations. The original media content and the instructional information may, or may not, be deleted. For example, in a "one-time-view" scheme, the original information is corrupted, whereas in a "pay-per-view" scheme, it is not corrupted.

Using the same techniques described above, a secure, or authenticated and secure connection may be established between two or more DVRs via a network or modem connection. Establishing such a connection enables control of the occurrence of the interaction. Some examples of control interactions provided in various embodiments are:

(1) and (5) synchronous playback. The viewer can feature trick-play for a particular media stream control. Each critical event is also transmitted to the destination DVR770, which automatically performs the same. For example, a publisher may provide real-time content to the source DVR110 as a multimedia playback device, while a remote viewer may view the same content at the same time and in the same manner. Alternatively, the two viewers may interact by communicating via some other means (e.g., telephone), where one or the other controls playback of the same program on both DVRs. This alternative approach allows for accurate discussion of content of interest. The communication means may be a simple chat program overlaid on the playing content, where the participants comment by typing. Such a method may be used for commercial presentations as well as for entertainment purposes.

(2) And (4) link transmission. The viewer of the source DVR110 may indicate that a particular program is linked to the destination DVR 770. In response, the source DVR110 sends a message to DVR770 to cause the destination DVR to set the recording time for the linked program. Optionally, the programs may also be unlinked. The information to link or unlink may contain only the program identification, assuming both DVRs 110 and 770 are in use. If the destination DVR770 is not running, the linking information may contain additional metadata.

(3) Sound or graphical effects. The source DVR110 may play a sound or display a graphic when the viewer takes an action, such as pressing a particular sequence of keys. The source DVR110 may also communicate the event to the destination DVR770, which replicates the same sound or graphics or a different sound or graphics in relation to the action taken. For example, a child may add sound to a program in this manner, which sound may be copied to a friend's remote destination DVR 770. Such communication may be multiplexed.

In another approach, the DVR may also transmit other types of data. For example, consider a large home DVR110 and a smaller portable DVR 760. Data such as software, graphics units, program guide data, etc. may be transmitted between the two DVRs. For example, the portable DVR 760 may be updated or data synchronized by the home DVR110 each time the two are connected. Updates may include transmitting and installing software updates, synchronizing program information, synchronizing recording schedules, and the like. Synchronization is very similar to a PDA, where portable DVR 760 can tell home DVR110 to delete a program because the user has already viewed it. The portable DVR 760 transmits the operation information to the home DVR110 whenever both are connected, and then, the home DVR110 transmits the operation information to the transmission center 130 whenever the home DVR110 accesses the service center 130.

The updating may be done automatically. In this case, when two DVRs are connected, a set of predefined actions is performed, such as updating a program guide or software, and then the media stream may also be transmitted. If destination DVR 760 is a smaller portable device, not all media streams will fit. In this case, the viewer can explicitly choose what media stream to transmit. Alternatively, application software in the source DVR may use the preference information to select a subset of the available media that is of most interest to the viewer, and only transmit those media streams. In another alternative, the media streams are transmitted in an order from newest to oldest, and stop when no longer appropriate, or in an order from oldest to newest. The time period delivery (all content played in the channel is recorded) may include an indicator to instruct the DVR to "transmit all the time" or "never transmit". Another criterion may be whether the program is explicitly selected or selected according to the viewer's preferences. Any program information stored in the object of the content description may be used to select criteria such as length, actors, rating, etc. The criteria may trigger an action such as "always transmit".

G. Network security mode

As described above, one approach herein provides for secure encrypted transmission of data between DVRs 110, 760, 770 or between content server 720 and DVRs 110, 760, 770. This method allows a user to record a program on one DVR110 and then view the program on another DVR 770.

The encrypted data transmission system described herein makes it difficult to transmit video from one DVR to any incompatible system or to systems outside the area where the first DVR is located. Thus, users may exercise reasonable "fair use" rights to their recorded content, but this approach makes it difficult for users to "pirate" videos, or send paid content to friends, in violation of "fair use" principles.

Various embodiments of the methods herein may include the following:

● the recorded content is encrypted. Many recorded content is encrypted as soon as recording is started.

Those recorded content that is not encrypted may be encrypted before being transferred from one DVR to another DVR. This makes it difficult for anyone to "sniff" and copy recorded data transmitted over the home network.

● when an encrypted recording is transferred from one DVR to another DVR, the receiving system cannot use the recording unless the sending system simultaneously transfers the encryption/decryption keys associated with the recording.

● the DVR may discover other systems from which to deliver recorded content through an IP broadcast mechanism or other network discovery protocol. In such discovery protocols, discovery packets do not typically leave the local IP subnet. In a residential environment, the local IP subnet comprises a home local area network. Additionally or alternatively, if there is a fear that a user may attempt to share recorded content with other users, the DVR application does not provide any mechanism that allows the system owner to type or otherwise manually specify other system IP addresses on the internet.

● the DVR may send only the encryption key for the recorded content to another DVR if the receiving system is authorized to view the recorded content, for example, in which case "authorized" may mean that the destination DVR is in the same home or that its owner is registered and authorized. Key transport employs a robust public/private key system in which each transported key is understood only by the system to which it was sent.

● authorization may be by way of a digital certificate that lists particular systems known to be part of a household or owned by a single user. The certificate includes the public key of the system and is "signed" by the service provider. Each system verifies the signature on the certificate it uses before transmitting any data or keys to any other system, while also verifying its own identity from the content contained in the certificate.

The certificate system can be based on an ElGamal public/private key system and Blowfish symmetric interception passwords. Blowfish symmetric interception passwords include self-checks that will intercept attacks such as "changing system serial numbers" or "copying certificates to different systems" or "changing certificates".

Referring to fig. 7 and 9, the user logs into service center 130 to create a recording of the DVR he wants to share content with. The user enters the desired DVR serial number using any suitable user interface, which service center 130 authenticates through its database, or service center 130 searches for a previously registered serial number for the user. Service center 130 may also restrict the user to only those DVRs whose user is the registered owner of the DVR that are displayed for selection. The user may name each device, such as the living room DVR, bedroom, etc., to facilitate identification of the device. The user selects the device with which he would like to share or transfer media.

The service center 130 creates a digital certificate 901 to identify the device selected by the user. Certificate 901 contains the serial number 903, 905 of each device, and the corresponding public keys 904, 906. The name that the user has taken for each device is also cross-referenced, as indicated in certificate 901 by name 902. The credentials may contain any number of devices identified by the user, including a PC with a USB adapter as described above.

To ensure that certificate 901 does not exist indefinitely, certificate 901 contains expiration date 907. The digital signature 908 is used so that a device receiving the certificate can verify that the certificate was indeed issued by the service center 130.

The service center 130 sends the certificate to each DVR110,770 listed on the certificate 901 via a network 140 (which may include the internet, a local area network, or other public or private network), a telephone line, or a satellite connection. The certificate 901 may be encrypted using the public key of each destination DVR110, 760, 770. The portable DVR 760 may be connected to the service center 130 via a network connection or a telephone line to receive its credentials. Alternatively, portable DVR 760 may receive its certificate from DVR110 to which it is connected.

Each DVR110, 760, 770 verifies the certificate by decrypting the certificate and verifying the digital signature 908 in the certificate 901. Once the DVR verifies that the digital signature 908 is from the service center 130, it searches for the network location of all peer DVRs listed in the certificate 901 using a peer discovery protocol, such as Rendezvous from Apple Computer inc.

Once DVR110 discovers peer 770 on the network, it establishes an encrypted connection with it using the peer public key from certificate 901. The encrypted connection may be "weakly" encrypted, which is a function of the two public keys, from each peer. Each peer sends information using the public key of the other. One device is designated as a content server, in this example, content server 720 is provided by a service provider and is remotely located.

Content server 720 creates a stronger encrypted connection with DVR110 by generating a random strong connection key and encrypting the strong key with the DVR's public key. Content server 720 then sends the encrypted strong key to DVR 110. DVR110 decrypts the strong key. In one approach, decryption may use a hardware decryption unit. The two systems now share a secure key.

The user may request that certain recorded content be sent to DVR 110. When content server 720 sends pre-encrypted recorded content to DVR110, it loads a recording key for encrypting recorded content from its database and encrypts the recording key using a strong key. Content server 720 sends the encrypted recording key to DVR 110.

DVR110 decrypts the recording key using its strong key shared with content server 720 and stores it. Content server 720 sends the recorded content that it stores locally to DVR 110. The recorded content is encrypted by content server 720 when initially stored locally. Content server 720 sends the recorded content without decrypting the content.

DVR110 writes the recorded content directly to its storage device without decoding it. When the DVR plays the recorded content, the content is decoded in synchronization (on the fly). The method described herein maintains the integrity of the recorded content because the content is encrypted during transmission and stored in the DVR, thereby preventing any form of unauthorized copying of the content.

If content server 720 sends unencrypted recorded content to DVR110, it creates a random recording key that is used to encrypt the recording and encrypts the recording key using the strong key. Content server 720 sends the encrypted recording key to DVR 110.

DVR110 decrypts the recording key using the strong key shared with content server 720 and stores the recording key. Content server 720 sends its locally stored encrypted content to DVR 110. The recorded content is not encrypted when it is initially stored locally by content server 720. The content server 720 encrypts the content while transmitting the content.

DVR110 writes the recorded content directly to the storage device without decoding. When the DVR plays the recorded content, the content is decoded synchronously. The method still maintains the integrity of the recorded content because the content is encrypted during transmission and stored in the DVR, thereby preventing any form of unauthorized copying of the content.

Fig. 10 shows a media server 1002 in a DVR connected to a local network established in a home 1001. In the example of fig. 10, DVR1003 is located in bedroom 1, DVR 1004 is located in bedroom 2, and DVR 1005 is located in the entertainment room. The media server 1002 is located in the living room. The user sends information to inform the service center 1006, DVRs 1003, 1004, 1005, and media server 1002 that content sharing authorization has been obtained and that each device is connected through the room in which they are located. The service center 1006 creates a certificate 901 that contains the serial number and public key of the media server 1002 and each DVR1003, 1004, 1005, along with the expiration date and digital signature of the service center.

The media server 1002 may be a PC, DVR, or other form of content server. The user designates the media server 1002 as the primary source of multimedia content in the local area network.

Service center 1006 sends credentials to media server 1002 and DVRs 1003, 1004, 1005 via internet 1007. The media server 1002 and DVRs 1003, 1004, 1005 use the information on the certificate to seek their peers. DVRs 1003, 1004, 1005 find that media server 1002 is the only system that provides content. Once the media server 1002 establishes a weakly encrypted connection with each DVR1003, 1004, 1005, it generates a random strong connection key for each DVR1003, 1004, 1005. The media server 1002 encrypts each strong key with the public key of the particular DVR and sends the encrypted strong keys to each DVR1003, 1004, 1005. The DVR decrypts the strong key using its local encryption chip. The media server 1002 then shares a security key with each DVR1003, 1004, 1005.

Referring to fig. 16-21, each DVR can access the content of the media server. Referring first to fig. 16, a user enters a Now browsing screen 1601 (similar in form and content to the Now browsing screen of fig. 6) and sees all media servers that the user can access. For example, the media server tag 1602 indicates that the user can access a DVR named "bedroom". The user selects the desired server using tab 1602, and a content screen 1701 (FIG. 17) is displayed listing the content available on the media server. A user may request that certain recorded content (music, pictures, videos, etc.) be sent to a particular DVR1003 via content screen 1701. The user may operate remotely as described above, or through the DVR1003 itself. The user selects to transmit the selected content option using the transmit options screen 1801 (fig. 18). The user can choose where to Start the transmission by using Start From option 1802. For example, the transmission may start from the beginning of the program, from where the user last paused, or at some point in the program. The user can view and transmit music content and picture content in the same manner as indicated in the screen shot 2001 in fig. 20 and the screen shot 2101 in fig. 21.

As described above with reference to fig. 10, the media server 1002 may send pre-encrypted recorded content to the DVR 1003. The media server 1002 loads the recording key used to encrypt the recorded content from its database and encrypts the recording key with a strong key. The media server 1002 may optionally encrypt the recording key with a local encryption key for storage in its database. It is generally undesirable to store any encryption keys in the clear, so simple encryption with a local key is optimal. It sends the encrypted recording key to the DVR 1003.

The DVR1003 decrypts the recording key using its strong key shared with the media server 1002 and stores the recording key. The DVR1003 may optionally encrypt the recording key with a local key prior to storage. The media server 1002 sends its locally stored recording to the DVR 1003. The recorded content is encrypted by the media server 1002 before it is initially stored locally. The media server 1002 sends the recorded content without decrypting the content.

The DVR1003 writes the recorded content directly to its storage device without decoding. When the DVR1003 plays the recorded content, the decoding is performed synchronously using the recording key. Referring to fig. 19, the user may select a program information screen 1901 to see if the program is still being transmitted. The user can Play the program by selecting the Play option 1902 or Stop the transmission using the Stop transmission option 1903 during the transmission (as described above).

If the media server 1002 sends the unencrypted recorded content to the DVR1003, it creates a random recording key to encrypt the recorded content and encrypts the recording key using the strong key. The media server 1002 sends the encrypted recording key to the DVR 1003.

The DVR1003 decrypts the recording key using its strong key shared with the media server 1002 and stores the recording key. The DVR1003 may optionally encrypt the recording key prior to storage using the local key. The media server 1002 sends its locally stored recording to the DVR 1003. The recorded content is not encrypted when initially stored locally by the media server 1002. The media server 1002 transmits the recorded content and encrypts the content at the same time as the transmission.

The DVR1003 writes the recorded content directly to its storage device without decoding. When the DVR1003 plays the recorded content, the decoding is performed synchronously using the recording key.

It should be noted that if attention needs to be paid to content copyright issues, the DVR1003 need not store the content on its storage device. It simply plays or displays the content immediately. If the content is encrypted, the DVR1003 decrypts synchronously.

The method described above works well in a local area network as well as in the internet.

H. Maintaining certificate consistency

Referring again to FIG. 11, creating a strong key takes many CPU cycles. In one approach, the DVR 1101 may be required to create and store multiple strong keys for later use, when the DVR 1101 is designated as a media server. Further, the receiving DVR requires many CPU cycles to decrypt the received strong key. This will significantly reduce the overall operating speed of the DVR. The techniques herein relieve DVR 1101 of the additional burden of creating a new strong key each time DVR 1102 is rebooted or restarted. It also relieves DVR 1102 of the burden of decrypting strong keys after a reboot or restart.

The DVR 1101 initially creates a strong join key and stores it in its local cache 1103 and encrypts it with the public key of the other DVR 1102. DVR 1101 sends the encrypted strong key to DVR 1102. DVR 1102 decrypts the strong key and stores it in its local buffer 1104, along with the encrypted strong key and the machine serial number of DVR 1101.

If DVR 1102 reboots or reboots, it does not know its status in the network. It may be down for a few seconds or be diverted from other networks. The DVR 1102 requests the strong key from the DVR 1101 designated as a media server. The DVR 1101 sends the strong key it stores in the local cache 1103 or creates a new strong key if the DVR 1102 has not yet established a strong connection with the DVR 1101. The strong key is encrypted with the public key of DVR 1102 and sent to DVR 1102.

When DVR 1102 receives the encrypted strong key, it checks the local cache 1104 for the directory of DVR 1101 and, if one is found, makes a bitwise comparison with the encrypted key 1104 in the local cache 1104. If the two keys are the same, then DVR 1102 uses the pre-encrypted key stored in buffer 1104. Otherwise DVR 1102 will decrypt the newly transmitted key and store the encrypted key, decrypted key, and DVR 1101 machine serial number in a new directory in local cache 1104. This approach eliminates the need for a long decryption step, unless it is necessary.

I. Internet media download

To facilitate downloading of media from an internet server to a DVR, fig. 12 shows a modification to the digital authentication ticket shown in fig. 9. Also, referring again to fig. 7, the service center 130 creates a certificate 901 that is assigned to the DVR110, 770. The DVR110, 770 will recognize the service directory using a special preset sequence number in the service sequence number field 903, such as: ffxxxxxxxxxxxxxx, where "xxxxxxxxxxxx" is used to provide additional information such as version number, service provider, etc. The display name 902 is set to indicate an item of a service, such as Special Video. The key fields 1204, 1206 are populated by fully qualified domain names of the server access points, rather than direct public keys.

Certificate 901 may contain a mix of server information and peer device information. Expiration date 907 and digital signature 908 remain unchanged.

Thus, the service center 130 may place information in the fields of all or a group of certificates to name the same or different servers, etc.

DVR110 recognizes the service serial number in the certificate and sends a ping command to the server using the domain name of the key field, e.g., key field 1204, to see if it can be reached. When a new DVR connects, the server checks the DVR's public key and uses it to generate other required keys. The DVR need not possess the server's key; the server generates a strong key for the session and encrypts the strong key using the DVR's public key. The encrypted strong key is then sent to the DVR.

Once communication is established, DVR110 can query the server for content.

The server synchronizes the appropriate metadata to describe the content that it can provide and sends it to DVR 110. Because the metadata is already synchronized, it can be uniquely created on a per DVR basis. For example, a DVR owner may sign up for different categories of services, such as history, drama, comedy, etc.

Alternatively, the server can instruct DVR110 to send its priority vector (referrence) to the server, which uses the priority vector to synchronize the appropriate metadata. The priority vector for the DVR includes the user's viewing habits, such as likes and dislikes explicitly indicated by the user, which he has recorded using options such as session pass customization (session pass subscription). The server does not store the priority vector information; it is simply deleted after use. This protects the privacy of the user and ensures that their preferences remain in the DVR110 at all times.

Standard video, music and image transmission interfaces are used as described above. Fig. 16 shows a Now Playing screen 1601 showing the DVR itself and other accessible servers and content 1602 that may be available in the DVR. The content directory of the service carries the relevant name in the listed certificate. In the same manner, content from another DVR, if any, is listed using the name 1602 associated with the user. In this way, the user knows the source of the content. Fig. 17 shows a content screen 1701 displaying the name of a content source 1702. Fig. 20 and 21 show a music content screen 2001 and an image content screen 2101.

Referring to fig. 13, a DVR ping (ping) server 1301, which is interested in downloading content from the server 1301. When a request from the DVR comes in, the server 1301 runs a ping service in response. This causes the server 1301 to keep a record 1302 of all DVRs that have all "signed up" to download the video. The recording 1302 may be reviewed at a later time to ensure, for example, that there are no clones from other IP addresses that access the available video's DVR. Record 1302 may also be used for billing to track how long a user has signed up to download video using their DVR 1303.

When a user selects a directory from server 1301 to transmit to DVR1303, DVR1303 contacts server 1301 and requests the appropriate media object. At this point, the server 1301 may record 1302 that the program is being downloaded, which may also include a directory of billing systems, etc.

User 1304 can query the records on the service center's website to easily check their bills.

Referring to fig. 14, a domain name redirector 1402 may be used to redirect a connection from a DVR 1401 to one of a set of third party servers 1403, 1404, 1405. Steering may occur on the basis of loading, domain name prefixes used, and the like. This allows the service center to forward the request to another company's server. Diversion may involve a problem of cost or revenue sharing in various embodiments.

The domain name redirector 1402 may reside on each third party server 1403, 1404, 1405, so the request from the DVR 1401 may be redirected by the third party server itself. The DVR 1401 requests a connection to a third party server 1403. The third party server 1403 "delegates" (delegat) its responsibility to the third party server 1404 by diverting requests from the DVR 1401 to the third party server 1404. The DVR 1401 then contacts the third party server 1404 to request the content requested by itself. This allows the third party server to decide itself whether to overload or for some reason not to be able to handle such requests.

J. Using DVR as an ENCRYPTION PIPELINE (ENCRYPTION PIPELINE)

Referring to fig. 15, content provided to DVRs 1503, 1504, 1505 may first be generated by a content server 1501, such as a third party content server. Content server 1501 does not have access to any information about DVR encryption technology or structure. The DVR 1502 is used to encode and encrypt content. DVR 1502 owns the fast network engine and acts as an "encryption pipeline". Data is sent from content server 1501 to DVR 1502. DVR 1502 encodes (if necessary) and encrypts data as it is written to its local storage device. The DVR 1502 then reads the data from the local storage device without decryption. And transmits the data to a destination DVR selected from among DVRs 1503, 1504, 1505 through the network.

Another approach provides a third party content server with secure content delivery. Data is sent from content server 1501 to DVR 1502 using the encryption techniques of the content server. The DVR 1502 decrypts the data using the content server's decryption technique. The DVR 1502 then encodes (if necessary) and encrypts (using the DVR's encryption technology) the data as it is written to its local storage device. The DVR 1502 then reads the data from the local storage device without decryption and sends the data over the network to the destination DVR selected from among the DVRs 1503, 1504, 1505.

This ensures that third party content providers do not have access to any sensitive information about the DVR's cryptographic chip, encryption technology, or addressing scheme. It further reduces time to market and the cost of integrating third party vendors into the content server network.

K. Accessing content via email

As described above, in any of the foregoing embodiments, the media server may be a PC, DVR, or any other device that may provide content. The methods described herein allow a DVR, a client that is a media server, to access multimedia content, such as music, video, and image content, stored on the media server. However, because DVRs and media servers may access the internet, content may not necessarily originate from or physically reside in any given media server.

Thus, the DVR user may obtain content by arranging for the server to process a particular file including:

● actual content (e.g. files in JPEG, MP3 or MPEG format)

● DVR configures settings such as recording schedules, database changes, content prioritization, etc.

● "links" another server or content stored on another server that may be located anywhere on the internet.

Such files may be provided via email or internet download. Two example scenarios described below illustrate how content can be sent to a DVR via email.

Referring to fig. 22 and 23, a typical home DVR equipment 2201 is shown. Assume that only the media server 2202 has access to the internet 2205. Email author 2204 creates a content file with authoring software. The file, for example, contains the actual binary data of several JPEG format images (which may contain any form of content). The content file is sent as an email attachment to the user who accesses the email from the same computer running the media server 2202. Messaging mechanisms other than email may also be used in alternative embodiments.

The user reads the email and, if the content is of interest, selects the attached content file, invoking the media server 2202 to process the content file. The media server 2202 adds information about the image to an internal database from which container (metadata) information and JPEG data may be subsequently generated.

The user enters his DVR2203 and accesses the "Music & Photo" ("Music and picture") feature through his television, causing the DVR2203 to request container information from the media server 2202. Of the other containers of available content displayed in the picture content display screen 2101 (fig. 21), the user can now access the one containing the image from the content file. When the user issues a command to view one of the images, the DVR2203 issues a request to the media server 2202, which queries its internal database, presents the appropriate JPEG data, and then transfers the data to the DVR 2003. The DVR2203 displays the pictures to the user, but does not save the pictures on its local storage device. The user can use trick-play functions such as fast-forward, pause, rewind, play (slide show), etc. for a plurality of picture files.

In fig. 23, a home DVR equipment 2301 is shown where both the DVR2303 and the media server 2302 can access the internet 2305. Author 2304 creates a content file with authoring software. The file is linked to one or more content files, such as MP3 music files, which are located in the content server 2306 and provided over HTTP. The content file is sent as an email attachment to the user who accesses the email (ideally) from the same computer running the media server 2302.

The user reads the email and, if the content is of interest, selects the attached content file, invoking the media server 2302 to process the content file. The media server 2302 adds information about the images to an internal database from which container information may be subsequently generated.

The user enters his DVR2303 and accesses the "Music & Photo" feature, causing the DVR2203 to request container information from the media server 2302. Of the other containers of available content displayed in the music content display screen 2001 (fig. 20), the client can now access the one container containing music from the content server 2306. When a user issues a command to play one of the music files, the DVR2303 directly accesses the media server 2306 through the internet 2305 to retrieve the appropriate data. The user may use trick play functions such as fast forward, pause, rewind, play, etc. on the music file. The process of playing music is presented to the user via the connected television set using the playback bar shown in fig. 8. The DVR2303 does not store music in its memory for copyright protection reasons.

As described above, the two previous examples may be for any type of content that a DVR may use or display. If configuration information is received, the DVR2303 will store the configuration information on its local storage device and use the configuration information to configure itself. If video is received, the DVR2303 may store the video content on its local storage device for later playback by the user. The user may use trick play functions on the video content such as fast forward, pause, rewind, play, slow play, frame forward play, and the like.

DVR users may use this method to share content with each other via e-mail. For example, one user may send a content file with a link to a personal picture in the first client PC to another user.

The methods herein may further be used for third party vendors to sell content to DVR users via e-mail. For example, a record label may promote a new album by sending a content file with a link to an MP3 file containing a sample song.

Third party partners may publish products to DVR users via email using the methods herein. For example, a video processing lab (film processing lab) may send a content file containing a digital picture that a DVR user purchased on the internet via email.

In the foregoing specification, the invention has been described with reference to specific embodiments. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (4)

1. A method for sharing multimedia content using a digital video recorder, the method comprising the steps of:

providing a media server;

providing a content database on the media server;

wherein the content database contains multimedia content and related metadata information;

providing a digital video recorder;

receiving an email containing a content file on the media server; and

wherein the content file comprises one or more of: audio content, video content, picture content, configuration information, a link to a server, or a link to content stored on a server;

wherein, the user reads the E-mail, selects the attached content file, and calls the media server to process the content file;

wherein the media server adds information about the content file to the content database;

wherein the user accesses the digital video recorder to request the retrievable content information from the media server;

the media server sends metadata information which can be obtained by content and comprises the content file to the digital video recorder;

wherein the digital video recorder displays the metadata information to the user, wherein the user selects the content file;

wherein the digital video recorder requests the content file from the media server;

wherein the media server streams the content file to the digital video recorder, wherein the digital video recorder plays or displays content contained in the content file, and wherein the user may perform trick-play functions on the displayed content, the trick-play functions including one or more of: fast forward, pause, fast rewind, play, slow play, frame forward play, or slideshow play.

2. The method of claim 1, wherein if the content file contains a file link to one or more content files on a server, the media server sends the content file on the media server to the digital video recorder, wherein the digital video recorder directly accesses the server over the internet to retrieve the one or more content files on the server, wherein the digital video recorder plays or displays content contained in the content file on the server, and wherein the user may perform trick play functions on the displayed content, the trick play functions including one or more of: fast forward, pause, fast rewind, play, slow play, frame forward play, or slideshow play.

3. An apparatus for sharing multimedia content using a digital video recorder, comprising:

a media server;

a content database in the media server;

wherein the content database comprises: multimedia content and associated metadata information;

a digital video recorder;

means for receiving an email containing a content file on the media server; and

wherein the content file comprises one or more of: audio content, video content, picture content, configuration information, a link to a server, or a link to content stored on a server;

wherein, the user reads the E-mail, selects the attached content file, and calls the media server to process the content file;

wherein the media server adds information about the content file to the content database;

wherein the user accesses the digital video recorder to request the retrievable content information from the media server;

the media server sends metadata information which can be obtained by content and comprises the content file to the digital video recorder;

wherein the digital video recorder displays the metadata information to the user, wherein the user selects the content file;

wherein the digital video recorder requests the content file from the media server;

wherein the media server streams the content file to the digital video recorder, wherein the digital video recorder plays or displays content contained in the content file, and wherein the user may perform trick-play functions on the displayed content, the trick-play functions including one or more of: fast forward, pause, fast rewind, play, slow play, frame forward play, or slideshow play.

4. The apparatus of claim 3, wherein the media server sends the content file on the media server to the digital video recorder if the content file contains a file link to one or more content files on the server, wherein the digital video recorder directly accesses the server over the internet to retrieve the one or more content files on the server, wherein the digital video recorder plays or displays content contained in the content file on the server, and wherein the user may perform trick play functions on the displayed content, the trick play functions including one or more of: fast forward, pause, fast rewind, play, slow play, frame forward play, or slideshow play.