System and method for local modulation and distribution of stored audio content

BACKGROUND

[0001] 1. Field of the Invention

[0002] This invention relates generally to the field of multimedia distribution systems. More particularly, the invention relates to a multimedia system for locally distributing stored audio content using modulation techniques supported by standard audio receivers.

[0003] 2. Description of the Related Art

[0004] Thirty years ago, only a limited number of multimedia devices were available to consumers. These included, for example, radio receivers for playing AM/FM radio, television sets for displaying broadcast video programs, turntables for playing vinyl records, and standard telephones for communicating across long distances. These devices were relatively easy to use and were the only devices capable of playing the media for which they were designed (e.g., a standard LP record could only be played back on a turntable).

[0005] Since that time, the digital revolution has produced a seemingly unlimited number of new multimedia devices. For example, audio and video content today may be digitally encoded on compact disks (“CDs”), digital video disks (“DVDs”), MiniDisks™, digital audio/video tapes, and VHS tapes. Moreover, with the proliferation of high speed Internet access through digital subscriber lines (“DSL”) and digital cable systems, consumers are frequently turning to the Internet to retrieve, store and play back audio and video content (e.g., in “MP3” or “MPEG-2” format, respectively).

[0006] In addition, the number of multimedia channels over which consumers receive audio, video, and data has increased significantly. Today these include standard broadcast television; digital/analog cable television; various direct-to-home satellite broadcast systems (e.g., DirecTV™, the Dish Network™); Internet service via dial-up, DSL and cable; AM/FM radio; and standard telephone service.

[0007] As a result, consumers are burdened with coordinating a variety of incompatible multimedia types and multimedia communication channels. This is not merely burdensome, but also costly and inefficient in that consumers are required to purchase a variety of different stand-alone decoder/playback and encoder/recorder devices, and subscribe to a plurality of incompatible multimedia services (e.g., standard telephone service, digital cable service, DSL Internet service, . . . etc).

[0008] In addition to the foregoing problems experienced by consumers, serious problems have arisen in recent years for artists and other content creators. More specifically, copyright infringement has become rampant due to the fact that digital audio and video can easily be copied from one media type to another without any noticeable loss in signal quality (e.g., from the Internet to a computer hard drive to a recordable compact disk).

[0009] Current device integration and home networking solutions such as those designed by the Universal Plug and Play Forum (“UPNP”), and Jini™ provide some level of interconnectivity between digital devices in the home. However, these solutions focus on connecting normally autonomous, stand-alone digital devices on a peer-to-peer network and, as such, often result in no cost savings to the end user. For example, the devices themselves are relatively expensive because they must be “smart” enough to function outside of the network environment and known network resources. In addition, these solutions can be extremely difficult to install and configure due to the fact that each device must be equipped with a proprietary interface for communicating to other devices on the network.

SUMMARY OF THE INVENTION

[0010] A system for locally broadcasting audio content is described, comprising: a multimedia recording apparatus having a mass storage device for storing audio content; a content selection module to select specific audio content from the mass storage device responsive to a user input; a decoder to decode the specific audio content using a specified decoding algorithm; a frequency modulation (“FM”) and/or amplitude modulation (“AM”) modulator to frequency-modulate and/or amplitude-modulate, respectively, the specific audio content; and a transmitter to broadcast the modulated specific audio content below a threshold broadcast power level and at a specified carrier frequency.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:

[0012]FIG. 1 illustrates a network architecture for implementing embodiments of the invention.

[0013]FIG. 2<i>a </i>illustrates one embodiment of a home media server hardware architecture.

[0014]FIG. 2<i>b </i>illustrates one embodiment of a home media server software architecture.

[0015]FIG. 3 illustrates a plurality of media modules installed in one embodiment of a home media server.

[0016]FIG. 4 illustrates one embodiment of a home media server which includes a DVD/CD/CD-RW drive.

[0017]FIG. 5 illustrates a home media server communicating to two audio/video media nodes over a wireless network.

[0018]FIG. 6<i>a </i>illustrates one embodiment of a multimedia node hardware architecture.

[0019]FIG. 6<i>b </i>illustrates one embodiment of a multimedia node software architecture.

[0020]FIG. 6<i>c </i>illustrates one embodiment of the system for tuning between multimedia channels.

[0021]FIG. 6<i>d </i>illustrates one embodiment of the system for playing a CD jukebox.

[0022]FIG. 7<i>a </i>illustrates one embodiment of a home media server for coordinating between standard telephone services and IP telephone services.

[0023]FIG. 7<i>b </i>illustrates one embodiment of a software architecture for implementing standard telephone, IP telephone and/or video conferencing.

[0024]FIG. 7<i>c </i>illustrates a signal diagram of communication between a home media server and telephone.

[0025]FIG. 8<i>a </i>illustrates a home media server coordinating between standard broadcast channels and packet-switched channels (e.g., the Internet).

[0026]FIG. 8<i>b </i>illustrates a potential progression of bandwidth allocation between packet switched channels and analog/digital broadcast channels.

[0027]FIG. 8<i>c </i>illustrates multimedia buffering according to one embodiment of the invention.

[0028]FIG. 9<i>a </i>illustrates a histogram showing a normalized bitrate for a particular multimedia stream.

[0029]FIG. 9<i>b </i>illustrates one embodiment of a system for intelligent bandwidth allocation and buffering.

[0030]FIG. 9<i>c </i>illustrates bitrate data normalized at one second intervals.

[0031]FIG. 9<i>d </i>illustrates bitrate data for three separate multimedia streams normalized at 10 second intervals.

[0032]FIGS. 9<i>e</i>-<i>m </i>illustrate histograms of normalized bitrate data for various DVDs.

[0033]FIG. 10 illustrates a cable television module according to one embodiment of the invention.

[0034]FIG. 11 illustrates a satellite module according to one embodiment of the invention.

[0035]FIG. 12 illustrates a cable modem module according to one embodiment of the invention.

[0036]FIG. 13 illustrates copyright tags implemented in one embodiment of the invention.

[0037]FIG. 14 illustrates one embodiment of a system for locally distributing audio content to a plurality of FM receivers.

[0038]FIG. 15<i>a </i>illustrates one embodiment of an apparatus for FM-modulating and transmitting multimedia content selected from a mass storage device.

[0039]FIG. 15<i>b </i>illustrates one embodiment of an apparatus for FM-modulating and transmitting multimedia content selected from a mass storage device at two different carrier frequencies.

[0040]FIG. 16 graphically illustrates one embodiment of a GUI for selecting specific audio content to be distributed at specific time periods.

[0041]FIG. 17 illustrates an external FM broadcast apparatus according to one embodiment of the invention.

DETAILED DESCRIPTION

[0042] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the invention.

[0043] Introduction

[0044] Digital multimedia recorder systems have become increasingly popular in recent years. These systems are capable of digitizing and storing audio and/or video content on hard drives which are currently between 5 and 100 Gbytes in size. Various types of multimedia recorders are available today including personal video recorders (“PVRs”), from companies such as Tivo™ and Sonicblue,™ which are capable of storing several hours of broadcast television programming; and digital music recorders such as the iPod™ from Apple Computer,™ which is capable of storing hundreds of hours of audio content copied from compact discs (“CDs”) or downloaded from the Internet.

[0045] An advanced digital recorder system (hereinafter “Media Server”) is described in the co-pending application entitled MULTIMEDIA AND COMPUTING SYSTEM, Ser. No. 09/653,964, Filed Sep. 1, 2000, which is assigned to the assignee of the present application and which is incorporated herein by reference. Certain aspects of this system will now be described followed by a detailed description of embodiments of a system for local FM broadcast. It should be noted, however, that the underlying principles of the invention may be implemented on virtually any type of digital multimedia recorder system. For example, the local FM distribution techniques described below may be employed on both advanced multimedia recorder systems (e.g., such as a Media Server) and standard multimedia recorder systems.

[0046] Embodiments of a Media Server

[0047] As illustrated in FIG. 1, in one embodiment of the invention, a digital media server <b>110</b> equipped with a processor and a mass storage device acts as a central repository for decoding, storing and distributing multimedia content and data. More particularly, the digital media server <b>100</b> coordinates multimedia content from Internet communication channels <b>120</b> (e.g., DSL, cable Internet), broadcast communication channels <b>130</b> (e.g., digital/analog cable, satellite), and/or Public Switched Telephone Network (“PSTN”) communication channels <b>170</b> (i.e., standard telephone) to provide a stable, real-time home media network <b>140</b> for a plurality of network devices <b>150</b>-<b>151</b>, <b>160</b>-<b>166</b>.

[0048] As illustrated in FIG. 2<i>a, </i>one embodiment of a home media server <b>110</b> computing architecture includes a central processing unit <b>200</b> capable of processing data and multimedia content stored in main memory <b>201</b> and a mass storage device <b>230</b> for storing data and multimedia content. In one embodiment, the central processing unit <b>200</b> is a Pentium®-class processor such as a Pentium III® operating at a 1 GHz or faster clock frequency. It should be noted, however, that the underlying principles of the invention are not limited to any particular processor speed or processor type. The main memory <b>201</b> may be a random access memory or any other dynamic storage medium (e.g., SDRAM, DDRAM, RD-RAM, . . . etc). The mass storage device <b>230</b> of one embodiment is capable of storing hundreds, or even thousands of hours of multimedia content (e.g., movies, digital audio, . . . etc) as well as other types of digital data (e.g., computer programs, word processing documents, . . . etc). Devices transmit and receive data to/from the mass storage device <b>230</b> over a high speed interface such as an enhanced IDE interface with Ultra DMA capabilities or a Small Computer System Interface (“SCSI”). However, various other interfaces may be employed while still complying with the underlying principles of the invention.

[0049] An application-specific integrated circuit (“ASIC”) <b>210</b> coordinates communication between the various system components and offloads certain designated processing tasks from the CPU. The ASIC may be custom built based on the requirements of the home media server <b>110</b> or may be built using gate arrays, standard cells or programmable logic devices.

[0050] Communication modules <b>240</b>-<b>245</b> electrically coupled to the home media server <b>110</b> via a system bus <b>220</b>, allow the home media server <b>110</b> to communicate over different local and remote communication channels. In one embodiment, the system bus <b>220</b> is a peripheral component interconnect (“PCI”) bus, although various other bus types may be configured within the home media server <b>110</b> (e.g., ISA, EISA, Micro Channel, VL-bus . . . etc).

[0051] In the particular embodiment illustrated in FIG. 2<i>a, </i>the communication modules <b>240</b>-<b>245</b> electrically coupled to the system bus <b>220</b> include an RF network module <b>240</b> for communicating over the home media network <b>140</b> (i.e., via a wireless RF channel), a cable TV module <b>241</b> for receiving broadcast cable channels, a cable modem module <b>242</b> for providing Internet access via a cable system (i.e., using the TCP/IP protocol), a satellite TV module <b>243</b> for receiving satellite broadcasts, and a DSL module <b>244</b> for DSL Internet access. Moreover, a virtually unlimited number of new modules may be added as necessary to support new or existing communication channels/protocols (as indicated by module <b>245</b>).

[0052] Other components within the home media server <b>110</b> architecture include an MPEG-2 decode module <b>202</b> (and/or other decode modules such as AC3, MPEG-1 . . . etc); an audio module <b>203</b> comprised of a digital-to-analog converter, a Sony-Philips Digital Interconnect Format (“SP-DIF”) interface and a standard telephony interface for providing digital and analog audio and standard telephone service to external audio/telephony devices; an Ethernet port provided directly the system ASIC <b>210</b> (as indicated by the “100 Base-T Ethernet” designation); a Firewire (IEEE 1394) port <b>204</b>; a Universal Serial Bus (“USB”) port <b>205</b>; and an infrared port <b>206</b>. Various other communication interfaces may be configured in the system, either directly on the primary home media server architecture <b>110</b> (e.g., on the media server <b>110</b> “motherboard”), or as an add-on module <b>240</b>-<b>245</b>. Moreover, the communication modules (e.g., <b>202</b>-<b>206</b>), the CPU <b>200</b> and/or the memory <b>201</b> may be incorporated within the system ASIC <b>210</b>, rather than as separate modules as illustrated in FIG. 2<i>a. </i>

[0053] Embodiments of the home media server <b>110</b> may also be equipped with a DVD drive, CD player, CD Read-Write drive, recordable DVD drive (as described in greater detail below), and/or any other type of portable storage medium <b>235</b>. In one embodiment, these devices may communicate with the home media server <b>110</b> via an AT Attachment Packet Interface (“ATAPI”), although the type of interface used is not pertinent to the underlying principles of the invention.

[0054]FIG. 2<i>b </i>illustrates a software architecture employed in one embodiment of the home media server <b>110</b>. Different hardware architectures <b>280</b> may be used to support the software, including the hardware architecture illustrated in FIG. 2<i>a. </i>A multitasking, multithreaded operating system (“OS”) <b>270</b> (e.g., Linux, UNIX, Windows NT®) with real time streaming support is executed on the hardware <b>280</b>. In one embodiment, certain proprietary customizations <b>292</b> are programmed in the media server OS <b>270</b> including, for example, real time services for streaming audio and video (real time OSs typically do not include these features).

[0055] A media toolkit <b>260</b> executed within the home media server <b>110</b> provides an application programming interface (“API”) for the different media server <b>110</b> applications described herein as well as a set of media server <b>110</b> utilities. In one embodiment, a minimum quality of service (“QoS”) is defined within the media toolkit <b>260</b>. The media toolkit <b>110</b> may be comprised of several functional layers including a media stream abstraction layer; a media stream resource management layer; a security/conditional access layer; and a transport/storage abstraction layer.

[0056] In one embodiment, the home media server <b>110</b> is configured with support for the realtime transport protocol (“RTP”) and the realtime streaming protocol (“RTSP”) (see, e.g., RTP/RTSP module <b>251</b>). Briefly, RTP is an IP protocol which supports real time transmission of voice and video. An RTP packet typically resides on top of a user datagram protocol (“UDP”) and includes timestamping and synchronization information in its header for proper reassembly at the receiving end. RTSP is a well known protocol for streaming multimedia content over a network. It should be noted, however, that various other streaming protocols may be implemented while still complying with the underlying principles of the invention (e.g., Quicktime®, Windows Media, . . . etc).

[0057] RTP and RTSP were designed primarily for PC to PC communication over non-realtime networks. Accordingly, because one embodiment of the home media server <b>110</b> operates over a realtime home media network <b>140</b> and communicates to devices other than PCs (e.g., media nodes <b>150</b>, <b>151</b>), certain optimizations <b>290</b> may be programmed within the RTP/RTSP component <b>251</b>. These include, for example, support for multiple data streams between the home media server <b>110</b> and the various multimedia devices <b>150</b>, <b>151</b>; <b>160</b>-<b>166</b> (e.g., one or more video streams and several audio streams).

[0058] Apache HTTP server support <b>250</b> is also included in one embodiment of the home media server <b>110</b>. Apache is an open-source HTTP server software product which may be executed on various modern desktop and server operating systems. Once again, certain media server customizations <b>290</b> may be included within the Apache component <b>250</b>, further refining HTTP support for the home media network <b>140</b> environment.

[0059] In one embodiment, a plurality of device servers <b>252</b> are executed on the home media server <b>110</b>. These devices servers provide application support for each of the media nodes <b>150</b>-<b>151</b> and other devices <b>160</b>-<b>166</b> communicating with the home media server <b>110</b> over the home media network <b>140</b>. For example, in response to a “tune” command sent from a media node <b>150</b>, a tuning device server will cause the home media server to tune to a broadcast channel specified by the tune command. The tuning server may also include conditional access functionality (i.e., only allowing tuning to occur for channels to which the user has access rights).

[0060] Although described above as a “software” architecture, it should be noted that various elements illustrated in FIG. 2<i>b </i>may also be implemented in firmware and/or hardware while still complying the underlying principles of the invention.

[0061] Referring again to FIG. 1, numerous digital and analog devices may be configured to communicate with the home media server <b>110</b> over the home media network <b>140</b>. By way of example, and not limitation, these include personal computers <b>160</b>, cameras or digital camcorders <b>161</b>, printers <b>162</b>, notebook computers <b>163</b>, automotive audio/video systems <b>164</b>, cell phones or personal digital assistants <b>165</b>, standard telephones <b>165</b> (including fax machines), home security systems (not shown); and/or home climate control systems (not shown).

[0062] In one embodiment, complex multimedia and data processing such as tuning to selected channels, recording of specified programs/music, storing phone numbers and personal data, connecting to remote network sites, etc., is performed at the media server <b>110</b>, rather than at the individual network devices <b>160</b>-<b>166</b>. As such, these devices <b>160</b>-<b>166</b> may be manufactured relatively inexpensively. For example, multimedia nodes <b>150</b>, <b>151</b> may be equipped with just enough processing power and memory to receive and play back a multimedia signal, with storage and control (e.g., tuning) functions offloaded to the home media server <b>110</b>. Similarly, a telephone <b>166</b> may be designed with nothing more than a low power microcontroller coupled to an RF transmitter, with telephony functions and contact data storage provided by the home media server <b>110</b>. In addition, because these network devices <b>160</b>-<b>166</b> do not require as much circuitry, they will be lighter than currently-existing devices, and will consume less power.

[0063] In one embodiment, the primary communication medium over which the home media server <b>110</b> and the various devices <b>150</b>-<b>151</b>, <b>160</b>-<b>166</b> communicate is wireless RF (e.g., via network module <b>240</b>), with terrestrial transport connections such as Ethernet reserved for devices which are not within RF transmission range. Moreover, certain devices which require a substantial amount of home media network <b>140</b> bandwidth (e.g., high definition television <b>170</b>), and/or devices which are in close proximity to the media server <b>110</b> may be configured to communicate over terrestrial transports, depending on the requirements of the particular configuration.

[0064] One Embodiment of a Multimedia Node Architecture

[0065] Distributed multimedia nodes <b>150</b> and <b>151</b> illustrated in FIG. 1 provide an interface to the home media network <b>140</b> for audio systems <b>170</b> (e.g., audio amplifiers and speakers) and/or video systems <b>171</b> (e.g., standard television sets, wide screen television sets, high definition television (“HDTV”) sets, or any other device capable of displaying video).

[0066] As illustrated in FIG. 6, one particular embodiment of a multimedia node architecture (see, e.g., node <b>150</b> in FIG. 1), is comprised of a network interface <b>605</b> coupled to the multimedia node bus <b>610</b> (e.g., a PCI bus); a system ASIC <b>620</b>, including MPEG-2 decode/graphics logic <b>630</b> (or other multimedia decode logic); a central processing unit <b>640</b> and memory <b>650</b>; an audio processing unit <b>660</b>; and/or an infrared port <b>670</b>.

[0067] The local central processing unit <b>640</b> and memory <b>650</b> execute programs and process data locally (i.e., at the multimedia nodes <b>150</b>, <b>151</b>). The network interface <b>605</b>, which may be an RF interface or a terrestrial interface (e.g., Ethernet), receives/transmits multimedia content and control data from/to the home media server <b>110</b> over the home media network <b>140</b>. The system ASIC <b>620</b> decodes and processes incoming multimedia content transmitted from the home media server <b>110</b> via MPEG-2 decode/graphics logic <b>630</b> (or other multimedia compression standard) to produce one or more video outputs <b>680</b> (e.g., an NTSC output, an HDTV output, . . . etc). In one embodiment, a separate audio processing unit <b>660</b> produces both digital and analog audio outputs, <b>681</b> and <b>682</b>, respectively. Moreover, one embodiment also includes a local mass storage device (not shown) for storing certain multimedia content and/or data (e.g., frequently-requested content/data).

[0068] In one embodiment, the local infrared interface <b>670</b> receives control commands from a remote control unit (e.g., unit <b>532</b> in FIG. 5) operated by a user. As described below with reference to FIG. 5, control data/commands received through the infrared interface <b>670</b> may subsequently be transmitted to the home media server <b>110</b> for processing. For example, in one embodiment, if a user selects a command to change to a live broadcast channel (e.g., the evening news), the command is transmitted from multimedia node <b>151</b> to a home media server <b>110</b> tuning application, which forwards the command to a video module (e.g., CATV module <b>241</b>, satellite TV module <b>243</b>). The tuner in the video module (see, e.g., tuner <b>910</b> in FIG. 9) then tunes to the requested frequency and the new video signal is streamed from the home media server <b>110</b> to the multimedia node <b>151</b>. Alternatively, or in addition, if the requested content was previously stored on the home media server <b>110</b> (e.g., on mass storage device <b>230</b>), then no broadcast tuning is necessary—the content is simply read from the storage device <b>230</b> and transmitted to the multimedia node <b>150</b>. Accordingly, as described in greater detail below, the amount of audio/video content which must be broadcast to the home media server <b>110</b> (i.e., over dedicated broadcast channels) is significantly reduced.

[0069] One embodiment of a multimedia node <b>150</b> software architecture is illustrated in FIG. 6<i>b. </i>Various hardware architectures <b>690</b> may be used to support the software architecture, including the architecture illustrated in FIG. 6<i>a. </i>An operating system <b>691</b> executed on hardware <b>690</b> (e.g., Windows '98, Linux, . . . etc) includes client customizations for optimizing communication over the home media network <b>140</b> (e.g., providing low level support for real time streaming of audio and video).

[0070] A standard set of user interface components <b>694</b> included in one embodiment may be employed (e.g., by application developers) to generate unique interactive interfaces at each of the media nodes <b>150</b>, <b>151</b>. For example, a user-navigable tuning index may be included which lists available content by dates/times and allows users to graphically select a particular broadcast channel and/or stored content from the mass storage device <b>230</b>.

[0071] In addition, support for the hypertext markup language (“HTML”) and/or the extensible markup language (“XML”) are included in one multimedia node <b>150</b> embodiment, allowing users to download, view and modify various types of Internet content (e.g., Web pages).

[0072] Applications executed on multimedia nodes <b>150</b>, <b>151</b> may include client-specific applications <b>697</b> and/or home media server <b>110</b> control applications <b>696</b>. Two examples of media server control application <b>696</b> will now be described with reference to FIGS. 6<i>c</i>-<b>6</b><i>d. </i>It should be noted, however, that these examples are for the purpose of illustration only and should not be read to limit the scope of the invention.

[0073]FIG. 6<i>c </i>illustrates an embodiment for tuning to a particular broadcast channel (e.g., cable, satellite broadcast). A user initially selects a particular channel (e.g., via a remote control device) to be viewed at the local multimedia node <b>151</b>. The command is received by the local TV tuning application <b>601</b> executed on the multimedia node <b>151</b>, which sends a tuning request to the home media server <b>110</b> over the home media network <b>140</b>. A tuner server module <b>602</b> executed on the home media server <b>110</b> receives the request and forwards the request to the tuner driver <b>271</b> (e.g., through the media toolkit <b>260</b>). In response to the command, the tuner driver <b>271</b> directs the tuner hardware (see, e.g., tuner <b>910</b> in FIG. 9 described below) to tune to the specified channel. The tuner driver also communicates with the conditional access subsystem (see, e.g., module <b>930</b> in FIG. 9) to determine whether the user has the right to view the particular channel (e.g., the channel may be a subscription-based channel such as HBO).

[0074] If the user has access rights, then the tuner server module <b>252</b> creates video stream for the specified broadcast channel and feeds the stream to the multimedia node <b>151</b>. In one embodiment, the tuner server module <b>602</b> creates the stream using the RTP/RTSP protocol (i.e., by communicating with the RTP/RTSP module <b>251</b>). The media node receives the stream through the local TV tuning application <b>601</b> and decodes the stream using a codec embedded within the media toolkit <b>260</b> (various additional encoding features of the system are set forth below). Once decoded, the video image is generated on the video display.

[0075]FIG. 6<i>d </i>illustrates an embodiment for employing a music jukebox at a multimedia node <b>150</b>. A user initially selects a particular music play list (e.g., via a remote control device) to be played at the multimedia node <b>150</b>. The request is received by a music jukebox application <b>601</b> executed on the multimedia node <b>150</b>, which forwards the request to the home media server <b>110</b>. A jukebox server module <b>604</b> executed on the home media server <b>110</b> receives the request and forwards the request to the media server file system <b>606</b> (through the media toolkit <b>260</b>), which retrieves the music files from the mass storage device <b>230</b>. The jukebox server module <b>604</b> then creates the audio stream for the specified files and feeds the stream to the multimedia node <b>150</b>. In one embodiment, the tuner server module <b>252</b> uses the RTP/RTSP protocol to create the stream (e.g., through communication with the RTP/RTSP module <b>251</b>). The multimedia node <b>150</b> receives the stream through its jukebox application <b>601</b> and decodes the stream using a codec embedded within the media toolkit <b>260</b>. Once decoded, the music tracks are reproduced on a set of speakers.

[0076] Network Operations Center

[0077] In one embodiment, a network operation center (“NOC”) <b>180</b> illustrated in FIG. 1 provides data and multimedia services for the home media server <b>110</b>. The NOC may be comprised of one or more servers communicating with the home media server <b>110</b> over the Internet <b>120</b> (or other network). In one embodiment, the NOC performs one or more of the following functions:

[0078] Remote Monitoring and Maintenance. The NOC <b>180</b> monitors the home media server to ensure that it is operating within normal parameters. In one embodiment, the home media server <b>110</b> periodically transmits a status update to the NOC <b>180</b>, indicating whether any particular services are required and/or whether any problems have arisen. If the home media server <b>110</b> fails to transmit a status update after a predetermined period of time, the NOC <b>180</b> may take steps to determine the cause of the problem and/or take steps to contact the user. For example, diagnostic tests may be performed to evaluate the network connection between the home media server <b>110</b> and the NOC <b>180</b>. If the diagnostic tests do not provide an answer, then the user may be contacted via telephone to determine the next course of action. In one embodiment the NOC <b>180</b> is staffed by engineers or other technical assistance personnel 24-hours a day.

[0079] In one embodiment, the user's home security system and/or fire system communicates with the home media server <b>110</b> over the home media network <b>140</b>. Accordingly, the home media server <b>110</b> may be programmed to relay home security and/or fire system data to the NOC <b>180</b> on a periodic basis during certain periods of time (e.g., every minute). If a security problem or fire trouble indication is encountered during this period of time (e.g., a door/window is opened without the proper security access code), the NOC <b>180</b> may notify a local law enforcement agency and/or the local fire department.

[0080] Automatic Downloading and Upgrades. In one embodiment, the NOC <b>180</b> provides automated software downloading and upgrades to the home media server <b>110</b>. For example, when a new software interface/program (e.g., a new graphical user interface) is developed for the home media server <b>110</b> it may be automatically downloaded from the NOC <b>180</b> and installed. Whether the NOC <b>180</b> should upgrade software on the home media server <b>110</b> automatically may be determined by each individual user. Certain users may opt to manually upgrade all of their software while other users may specify a particular subset of software to be automatically upgraded. For example, a user may specify automatic upgrades for graphical user interface software and manual upgrades for email clients and word processors.

[0081] In addition, the NOC <b>180</b> may store up-to-date drivers for various home media network devices <b>160</b>-<b>166</b>. In one embodiment, when a user purchases a new device, such as a new telephone, the device may automatically identify itself to the home media server <b>110</b> (e.g., via USB, IEEE 1394 or other device identification technology). The home media server <b>110</b> will then determine whether the device is supported by the system and, if so, query the NOC <b>180</b> for the latest driver. In one embodiment, once the driver is identified, it is automatically downloaded from the NOC <b>180</b> and installed on the home media server <b>110</b>. Once installed, the driver may be updated automatically as new updates become available. Accordingly, driver software will no longer need to be bundled with home network devices <b>160</b>-<b>166</b>, resulting an additional cost savings to the end-user. In addition, users will not be required to install and configure device drivers for each new network device they purchase.

[0082] In addition, the home media server <b>110</b> may check the NOC <b>180</b> to determine whether the home network device has been certified by the NOC <b>180</b> as meeting some minimum level of quality and/or performance. In one embodiment, device drivers will be downloaded and installed on the system only if the device has been certified. In this manner, a minimum quality of service may be maintained for all devices employed on the system.

[0083] The same type of device identification, certification, and driver installation may be performed for communication modules <b>240</b>-<b>245</b> such as those described above. Thus, as with home network devices <b>160</b>-<b>166</b>, certain communication modules <b>240</b>-<b>245</b> which do not meet a minimum quality of service requirement (e.g., those which perform inefficient bus transactions which tie up the system bus <b>220</b>) will not be certified by the NOC <b>180</b> and will not be permitted to be installed in the home media server <b>110</b>.

[0084] In addition, in one embodiment the communication modules <b>240</b>-<b>245</b> are manufactured and certified by third party content providers (e.g., satellite broadcast operators). In this embodiment, the content providers may configure the modules <b>240</b>-<b>245</b> to work with their own proprietary communication protocols, encryption techniques, and/or application programs. For example, DirecTV™ may develop a proprietary interface for its users so that when a user selects his DirecTV feed he will be presented with a unique user interface and/or channel programming environment. Accordingly, while the present invention provides a standard media transport interface for a variety of different communication channels, service providers can still distinguish their services based on the proprietary applications/transports which they develop.

[0085] Logging/Data Warehousing. In one embodiment, the NOC <b>180</b> may perform logging and data warehousing for the home media server <b>110</b>. More specifically, the NOC <b>180</b> may maintain a log of network transactions for each home media server <b>110</b> and subsequently evaluate the log for a variety of reasons (e.g., to troubleshoot system problems, to determine a user's preferences and tailor services and/or advertising to that user, . . . etc). For example, by monitoring usage patterns, the NOC <b>180</b> may determine that every time a certain Java applet is downloaded, the home media server <b>110</b> crashes. As such, the NOC <b>180</b> may takes steps to ensure that the applet in question is no longer downloaded by the home media server <b>110</b> (e.g., by notifying the user or automatically blocking the applet). The NOC <b>180</b> could then notify the technical support staff to determine the problem with the applet.

[0086] Similarly, the usage log may be evaluated to determine the preferences of a user and to provide specialized services to that user based on those preferences. For example, based on the Web sites the user visits and/or the channels that the user watches, the NOC <b>180</b> may determine that the user is interested in baseball. As such, the NOC <b>180</b> may automatically provide baseball-related content to the user such as, for example, broadcast schedules for upcoming games, a subscription offer to a sports magazine, advertisements, and various other baseball-related content. Similarly, the NOC <b>180</b> may determine that the user watches certain television shows on a regular basis, and may automatically download/record those shows on the home media server <b>110</b> (e.g., via TCP/IP), so that they will be readily available for the user (e.g., during non-broadcast periods of time).

[0087] Archiving. In one embodiment, users may backup multimedia content and other types of data at the NOC <b>180</b>. For example, a user may take a series of pictures with a digital camera and transmit the originals to the NOC <b>180</b> for developing. In one embodiment, the NOC will transmit the pictures to a developer on behalf of the user and will store a backup copy of each of the originals (the NOC <b>180</b> will be backed up regularly to prevent loss of the originals).

[0088] In one embodiment, the NOC <b>180</b> will monitor all multimedia content purchased by the user over the Internet. For example, when the user downloads a new compact disk (“CD”) from a music download site, the NOC <b>180</b> will record the transaction in the user's profile. As such, the user does not need to store all of his/her multimedia content locally on the home media server <b>110</b>. Rather, because the NOC <b>180</b> keeps track of all the content to which the user has access rights, the user can offload storage to the NOC <b>180</b> and re-download the content when necessary (e.g., following a hard drive failure on the home media server <b>110</b>).

[0089] Registration/configuration. In one embodiment, users may be required to register with the NOC <b>180</b> upon purchasing a home media server <b>110</b> and related network devices <b>150</b>-<b>151</b>, <b>160</b>-<b>166</b>. The NOC <b>180</b> may prompt each user to respond to a series of question directed to the user's preferences, the type/level of NOC <b>180</b> services desired by the user, the authorization level of each user in the home media server <b>110</b> household (e.g., children may be provided with limited limited functionality), and any other user-related data which may aid the NOC <b>180</b> in providing user services. In one embodiment, the NOC <b>180</b> will automatically detect the home media server <b>110</b> configuration and store this data in a user database (e.g., to be used for software upgrades, troubleshooting, . . . etc).

[0090] Bridge to Satellite/Cable Operations. In one embodiment, the NOC <b>180</b> will coordinate communication between the home media server <b>110</b> and any satellite/cable services to which the user has subscribed. For example, the NOC <b>180</b> may forward pay-per-view requests transmitted from the home media server <b>110</b> to the various cable/satellite operators, and perform the back-end processing (e.g., authentication, billing) required for the pay-per-view transaction. Because a persistent communication channel exists between the NOC <b>180</b> and the home media server <b>110</b> (e.g., through DSL or cable modem), no dial-up processing is required (unlike current pay-per-view cable and satellite systems).

[0091] E-commerce Support. In one embodiment, rather than acting merely as a conduit between the home media server <b>110</b> and other e-commerce Internet sites, the NOC <b>180</b> may perform various e-commerce functions itself. For example, the NOC <b>180</b> may market and sell products on behalf of other online retailers (e.g., Amazon.com®). The NOC <b>180</b> of this embodiment may perform the back-end processing (e.g., billing and record keeping) required for each e-commerce transaction.

[0092] Application Support. In one embodiment, the NOC <b>180</b> will provide support for applications executed on the home media server <b>110</b>. For example, the NOC <b>180</b> may provide a compact disk database containing CD titles, track information, CD serial numbers, etc. When a user copies his CDs onto the mass storage device <b>230</b> of the home media server <b>110</b>, the home media server <b>110</b> may query the database (as described in greater detail below) and download title and track information (or other information) used to identify/index each CD and each track. In one embodiment, public CD databases (e.g., such as the database maintained at “www.cddb.com”) may be filtered and improved by the NOC <b>180</b> to remove errors. Various other types of application support may be implemented at the NOC <b>180</b> consistent with the underlying principles of the invention.

[0093] Remote-Access Gateway. In one embodiment, the NOC <b>180</b> may be used as a gateway to access to the home media server <b>110</b> from a remote location. For example, a user from a PC connected to the Internet may log in to his home media server <b>110</b> through the NOC <b>180</b>.

[0094] In one embodiment, the home media server <b>110</b> is configured to make outgoing connections only (i.e., to reject direct incoming connections). As described briefly above, the home media server <b>110</b> may poll the NOC <b>180</b> periodically (e.g., every few seconds) and transmit a status update. During this periodic poll the home media server <b>110</b> may query the NOC <b>180</b> to determine whether anyone is attempting to access the home media server <b>110</b> from a remote location. If so, then the NOC <b>180</b> transmits specific information related to the connection attempt to the home media server <b>110</b> (e.g., authentication data such as user ID's, passwords, . . . etc). The home media server <b>110</b> may then initiate a connection with the remote user (e.g., using the remote user's IP address and encryption key).

[0095] In one particular embodiment, the NOC <b>180</b> will authenticate the remote user before notifying the home media server <b>110</b> of the connection attempt. For example, upon receipt of a remote connection request, the NOC <b>180</b> may prompt the user to answer a series of questions (e.g., personal questions, questions related to the user's account, . . . etc). If the user does not answer the questions in a satisfactory manner, a member of the NOC staff may contact the user directly (e.g., via standard telephone or IP telephone). Regardless of how authentication takes place, once a remote user is authenticated, the user's data is transmitted to the home media server <b>110</b>, which subsequently establishes a connection with the remote user.

[0096] Additional Home Media Server Embodiments and Applications

[0097] An external illustration of one embodiment of the home media server <b>110</b> is shown in FIGS. 3 and 4 (from the back and front, respectfully). FIG. 3 shows a home media server <b>110</b> with a plurality of different media modules <b>320</b>-<b>325</b> installed in its expansion bays (i.e., electrically coupled to its system bus <b>220</b>). As illustrated, in one embodiment, certain standard communication ports such as Ethernet <b>301</b>, IEEE 1394 <b>302</b>, USB <b>303</b>, digital/analog audio <b>305</b>, standard telephone <b>304</b>, XGA/HDTV <b>306</b>, and/or other standard audio/video ports (e.g., AV output ports <b>307</b> and <b>308</b>) may be installed directly in the primary home media server, rather than as an expansion card.

[0098] As illustrated in FIG. 4, one embodiment of the system includes a DVD player <b>420</b> (and/or a CD player, CD-ReWritable drive, recordable DVD drive or other type of portable digital media player/recorder). The DVD player <b>420</b> is capable of playing a DVD directly and/or transferring multimedia content from the DVD to the mass storage device <b>230</b>. In one embodiment, as multimedia content is transferred to the storage device <b>230</b>, either from the DVD player <b>420</b> or over the Internet <b>120</b>, an indexing module executed on the home media server <b>110</b> indexes the multimedia content in a content database (not shown).

[0099] Various DVD/CD identification techniques may be used to identify the particular DVD/CD inserted and copied to the storage device <b>230</b>. For example, a checksum may be calculated for a known unique portion of the DVD/CD and compared with a CD/DVD checksum database (e.g., maintained at the NOC <b>180</b> or other server). Similarly, the serial number may be read from the DVD/CD and compared with a database of DVD/CD serial numbers. Additional DVD/CD identification techniques which may be utilized in accordance with the principles of the invention are disclosed in co-pending applications entitled SYSTEM AND METHOD FOR SCALING A VIDEO SIGNAL, Ser. No. 09/632,458, filed Aug. 4, 2000 which is assigned to the assignee of the present application and which is incorporated herein by reference.

[0100] In one embodiment of the system, the storage device <b>230</b> (e.g., a hard drive) is preferably large enough to store hundreds of hours of video and/or audio content, as well as a variety of other digital information such as telephone voice messages, computer programs/data . . . etc. The current recommended size for the storage device <b>230</b> is at least 80 gigabytes, however the particular size of the storage device is not pertinent to the underlying principles of the invention.

[0101] One or more RF transmitters <b>430</b> are also provided in one embodiment of the home media server <b>110</b>. The transmitter <b>430</b> (as well as the LAN <b>390</b>, if one is installed) allows the home media server <b>110</b> to simultaneously transmit multimedia content and other types of data to the various media devices <b>150</b>-<b>151</b>, <b>160</b>-<b>166</b> over the home media network <b>140</b> (e.g., at least one MPEG-2 video stream and several audio streams).

[0102] In one embodiment, the wireless transmission system is capable of handling isochronous multimedia traffic reliably (i.e., without jitter) in a wide range of residential settings. For example, the system must be capable of working in the presence of common residential RF interference such as microwave ovens and cell phones. In one embodiment, these requirements are met through the proper choice of modulation and coding. More specifically, one embodiment employs a modified version of IEEE 802.11b adapted to operate in a real time environment (e.g., using Reed-Solomon forward error-correction and antenna diversity with circular polarization).

[0103]FIG. 5 illustrates a home media server <b>110</b> communicating simultaneously with a video node <b>520</b> and an audio node <b>522</b>. Certain multimedia nodes, such as node <b>522</b>, include an LCD <b>524</b> (or other type of display) for displaying information about the multimedia content stored on home media server <b>110</b> (e.g., CD and movie titles, CD tracks . . . etc). In one embodiment, the audio node <b>522</b> may be electrically coupled to an amplifier for amplifying the transmitted audio signal into a pair of speakers. As described above, in one embodiment, the individual multimedia nodes also include local storage devices (not shown) for locally caching recently used multimedia content and data.

[0104] Data/commands sent from remote control devices <b>530</b>, <b>532</b> are transmitted through the nodes <b>520</b>, <b>522</b> to the home/media server <b>110</b> as indicated. In one embodiment, the remote control devices include an LCD (not shown) or other type of display for displaying information about the multimedia content stored on home media server <b>110</b> (i.e., instead of, or in addition to, the multimedia node <b>522</b> display <b>524</b>).

[0105] As described briefly above, using the foregoing system, all of a user's data, music and video may be stored in a single location (i.e., home media server <b>110</b>) and accessed from anywhere in the house (e.g., stereo node <b>522</b>) or the car (e.g., via an automotive multimedia node <b>164</b> as indicated in FIG. 1). Moreover, if the home media server <b>110</b> is connected to the Internet through, for example, a persistent DSL connection <b>360</b>, the user can access all of the stored content from various other locations across the globe (e.g., a summer home or a hotel while away on business). One embodiment of the system provides a secure, encrypted data stream when content/data is requested from the home media server <b>110</b> in this manner, thereby protecting the user's privacy as well as the copyrights to the underlying multimedia content.

[0106] If a multimedia node is employed in a user's automobile as described above, when the automobile is parked within range of the media server's RF transmissions, music or other audio/video content may be transmitted and stored on a storage device within the automobile, even when it is not running. The specific type of audio/video content to be transmitted at a particular time during the day or week may be variable, based on users' preferences. For example, the home media server <b>110</b> may be configured to transmit up-to-date traffic reports during the morning and evening hours before the user leaves home/work. The user will then receive an instant traffic report as soon as he starts his car in the morning and/or evening, followed by music or video selected based on the user's preferences. Various additional aspects of this feature are set forth in the co-pending applications incorporated by reference above.

[0107] In an embodiment which includes a CD-ReWritable (“CD-RW”) drive, users can produce custom CDs using the audio content stored on the mass storage device <b>230</b> or downloaded from the Internet. The CD-RW drive may utilize serial copy management techniques to produce CDs which cannot themselves be copied, thereby protecting the copyrights to the underlying works. Moreover, in one embodiment, the system will determine whether the content owner or content creator allows copying of the multimedia content. For example, certain content creators/owners may allow a copy to be stored on the home media server mass storage device <b>230</b>, but may not allow copying to a portable disk (e.g., a CD-RW disk). In one embodiment, content stored on the mass storage device <b>230</b> may be labeled as non-copyable by setting one or more “copy” bits to a particular value (e.g., in a bit field associated with the content).

[0108] In one embodiment of the system, a portable music/video player node may be configured to retrieve multimedia content directly from the home media server <b>110</b> or via an adapter module. Portable MP3 players such as the Rio™ from Diamond Multimedia™, for example, may be used to store and play back digital audio content transmitted from the home media server in a flash memory module. In one particular embodiment, the CD-RW drive <b>420</b> is capable of accepting the ⅓ inch “mini CD” format. Accordingly, users may produce unique mini CDs (e.g., using tracks stored on the mass storage device <b>230</b>), for playback on MP-3 players capable of playing mini-CDs.

[0109] MPEG conversion logic is configured on one embodiment of the home media server <b>110</b> (e.g., in software, hardware or any combination thereof), allowing the home media server <b>110</b> to convert from one MPEG format to another. Using the MPEG conversion logic, video content stored in MPEG-2 format may be converted to MPEG-1 format and recorded on a “video CD” (a compact disc format used to hold full-motion MPEG-1 video). As such, users may store video on a portable medium, even on a home media server <b>110</b> which is not equipped with a recordable DVD drive.

[0110] In another embodiment of the system, home appliances (e.g., the refrigerator, the toaster, the air conditioner) and other home systems (e.g., security, air conditioning) are all provided with RF transmission devices to communicate with the home media server <b>110</b>. Each device may also be configured with it's own internal network address and/or Internet address. Users may then access information pertaining to these devices and/or control these devices from any room in the home or over the Internet. In one particular embodiment, the user's automobile is outfitted with an RF transmitter and a network address. Thus, in this embodiment, the automobile is capable of reporting maintenance information to the user via the home media server <b>110</b> (e.g., low brake pads, oil change needed . . . etc).

[0111] In one embodiment, a user may publish a home Web page containing up-to-date information on each home appliance or other network device. Accordingly, users of this embodiment are able to monitor and control home appliances and systems from anywhere in the world. In one embodiment this includes the ability to select broadcast listings and direct the home media server <b>110</b> to make recordings (e.g., based on date/time or broadcast ID code). In addition, in one embodiment, users may connect remotely to the home media server to review email and/or voicemail listings (which may be displayed to the user in the form of a single, generic “message” box). Voicemail messages may be streamed to the remote user's location over the Internet or other network.

[0112] Telephony Embodiments

[0113] As illustrated in FIG. 7<i>a, </i>in one embodiment, home telephone devices <b>166</b> may also be configured to run through the home media server <b>110</b>. In this embodiment, incoming faxes and voicemail are stored on the home media storage device <b>230</b> and may be accessed from any room in the house (e.g. from telephone devices <b>166</b>, personal computers <b>160</b>, PDAs <b>165</b>, and/or video systems <b>151</b>/<b>171</b>). In addition, phone number and address information may be stored in a contact database <b>740</b> on the home media server <b>110</b> and accessed through the various telephone devices <b>166</b> (or other home media devices). Offloading user contact data from the telephone devices <b>166</b> in this manner allows telephone devices <b>166</b> to be manufactured will less memory and less processing power, further decreasing costs to the end user.

[0114] As illustrated in FIG. 7<i>a, </i>in one embodiment, the home media server <b>110</b> includes a telephone connection module <b>730</b> which coordinates between standard telephony calls placed/received over the public switched telephone network (“PSTN”) <b>170</b> and calls placed over the Internet <b>120</b> using IP telephony protocols. The telephone connection module <b>730</b> will automatically route incoming calls from both sources to the same set of home telephone devices <b>166</b> (or other home media devices such as the user's personal computer <b>160</b>).

[0115] Users may specify whether a particular outgoing call should be placed over the Internet <b>120</b> (e.g., to an IP telephony device <b>710</b>) or over the PSTN <b>170</b> (e.g., to a standard telephone device <b>720</b>). In one embodiment, the telephone connection module <b>730</b> analyzes each outgoing telephone connection request to determine whether the call should be routed through the Internet <b>120</b> or through the PSTN <b>170</b>. The telephone connection module <b>370</b> may factor in various types of connection data to make telephone connection determinations. For example, a user may specify certain contacts within the contact database <b>740</b> for which IP telephone connections should be used and certain contacts for which standard telephone connections should be used. In one embodiment, the telephone connection module <b>730</b> will select a particular connection based on whether it is the least expensive option for the user (e.g., for contacts with both IP and standard telephone capabilities). Another variable which may be factored into the selection process is the connection throughput available to the user over the Internet. More specifically, the telephone connection module <b>730</b> may initially test the connection throughput (including the availability of a reliable connection) over the Internet <b>120</b> and place an IP telephony call only if some minimum level of throughout/reliability is available. Any of the foregoing variables, alone or in combination, may be evaluated by the telephony connection module <b>730</b> to select and appropriate telephone connection.

[0116] One embodiment of a protocol architecture for supporting IP telephony and related communication functions on the home media server <b>110</b> is illustrated in FIG. 2<i>b. </i>Various telecommunication standards are supported by this embodiment, including the H.248 media gateway control standard (“MEGACO”) standard; the ITU-T H.323 and session initiation protocol (“SIP”) standards for multimedia videoconferencing on packet-switched networks; the Realtime Control Protocol (“RTCP”) standard—a companion protocol to the realtime transport protocol (“RTP”) (described above) used to maintain a minimum QoS; and the ITU T.120 standard for realtime data conferencing (sharing data among multiple users).

[0117] In addition, various audio and video codecs are supported by the illustrated embodiment, including G.711, G.723, and G.729 (for audio); and H.261 and H.261 (for video). As illustrated, each of these codecs may be executed above RTP, an IP protocol that supports realtime transmission of voice and video. Each of the foregoing IP communication protocols may be utilized by media server <b>110</b> application programs through the programming interfaces of the media toolkit <b>260</b>.

[0118] It should be noted that, although the embodiment illustrated in FIG. 7<i>b </i>includes a specific set of communication protocols, various other communication protocols may be implemented within the home media server <b>110</b> while still complying with the underlying principles of the invention. For example, in one embodiment, new protocol stacks (both proprietary and industry-standard) may be automatically transmitted from the NOC <b>180</b> and installed on the home media server <b>110</b> as they become available.

[0119]FIG. 7<i>c </i>illustrates a signal diagram representing the set up and termination of a telephony connection according to one embodiment of the home media server <b>110</b>. At <b>750</b>, the home media server transmits a call connection “invitation” on behalf of User 1 to User 2. Once User 2 accepts the call, a “success” message is transmitted back to the home media server <b>110</b> at <b>751</b>. In response, the home media server <b>110</b> acknowledges receipt of the “success” message at <b>752</b> and allocates a media stream <b>760</b> to support bi-direction audio communication between User 1 and User 2. To tear down the media stream <b>760</b>, one of the users must hang up the phone, resulting in a “bye” message <b>753</b>, <b>754</b> followed by a termination acknowledgement (“success”) from both sides <b>755</b>, <b>756</b>.

[0120] Broadcast and Packet-Switched Channel Coordination

[0121] In one embodiment illustrated in FIG. 8<i>b, </i>content providers <b>830</b> may transmit content to home media server <b>110</b> over Internet channels <b>120</b> as well as standard broadcast channels <b>170</b>. The transmitted content may then be cached locally in a content database <b>850</b>. When a user subsequently requests the same content to be played back on an audio device or video device <b>171</b> (e.g., via media node <b>151</b>), it will be replayed to the user directly from the local content database rather than over a broadcast channel. In one embodiment, a content selection module <b>840</b> will determine whether to retrieve the content through a broadcast channel or directly from the content database <b>850</b>.

[0122] In one embodiment, the home media server <b>110</b> and/or the content provider <b>830</b> will monitor the preferences of each user in the media server <b>110</b> household to determine the content which will be requested during certain times of the day, and/or days of the week. For example, if a user watches “the Simpsons®” at 6:00 PM, the home media server <b>110</b> and/or content provider <b>830</b> will record this behavior. The content provider <b>830</b> may then transmit the latest Simpsons episode to the home media server <b>110</b> over the Internet <b>120</b> before its scheduled broadcast at 6:00 PM (e.g., during periods of the day or evening when traffic on the Internet <b>120</b> is low). Various other pre-recorded broadcast programs may be transmitted to the home media server <b>110</b> over the Internet rather than over a dedicated broadcast channel, thereby freeing up a substantial amount of inefficiently used broadcast network bandwidth (pre-recorded content currently represents the vast majority of all broadcast content).

[0123] As indicated in FIG. 8<i>b, </i>this embodiment of the home media server <b>100</b> will provide a seamless mechanism for transitioning from standard digital broadcast channels (e.g., MPEG-2 channels) and analog broadcast channels to packet switched isochronous channels (for live broadcasts) and asynchronous channels (for pre-recorded broadcasts). Initially, the breakdown between broadcast and packet switched channels (e.g., TCP/IP) will be similar to that illustrated in column <b>804</b>, with analog broadcast <b>803</b> taking up approximately half of the available bandwidth, with the other half split between digital broadcast <b>802</b> and packet switched channels <b>800</b>. As content providers begin to switch over to a packet-switched transmission scheme, this breakdown will change as indicated at bandwidth allocation <b>805</b>, with packet-switched channels taking up approximately half of the available bandwidth and the remainder split between analog broadcast <b>812</b> and digital broadcast <b>811</b>.

[0124] Finally, when standard analog and digital broadcast channels have been phased out completely, all content will be delivered over packet switched channels as indicated in bandwidth allocation <b>806</b>. Many packet switched protocols support both asynchronous and isochronous data transmissions. Accordingly, several isochronous channels may be provided to support live, real time events (e.g., sports events, the evening news, . . . etc) and the remainder of the bandwidth may be allocated to pre-recorded events (e.g., sitcoms, game shown, talk shows, . . . etc). These pre-recorded events/shown may be asynchronously downloaded to the home media server <b>110</b> at any time of the day or evening (e.g., during periods of low network activity), resulting in a much more efficient allocation of available transmission bandwidth.

[0125] Because embodiments of the home media server <b>110</b> described above are capable of receiving, storing and coordinating content transmitted from both packet switched channels (e.g., TCP/IP) and standard broadcast channels, the transition illustrated in FIG. 8<i>b </i>may be accomplished seamlessly, while at the same time improving the overall quality of service to the end user.

[0126] In one embodiment, several concurrent, real-time multimedia streams are supported by the home media server <b>110</b> through buffering and/or disk storage techniques as illustrated in FIG. 8<i>c. </i>More specifically, incoming multimedia content <b>860</b>-<b>862</b> from several different channels (e.g., standard broadcast channels <b>860</b>, <b>861</b> and packet switched channels <b>862</b>, <b>863</b>) may be buffered in a set of input buffers <b>870</b>-<b>873</b> and output buffers <b>890</b>-<b>893</b> on the home media server <b>110</b>. The input buffers and output buffers <b>870</b>-<b>873</b> and <b>890</b>-<b>893</b>, respectively, may be portions of memory allocated within the main memory <b>201</b> (see FIG. 2). Alternatively, or in addition, the input/output buffers may be configured on the communication modules <b>240</b>-<b>245</b>, within the system ASIC <b>210</b>, and/or as separate modules on the home media server <b>110</b> motherboard.

[0127] In one embodiment, the mass storage device <b>230</b> reads the multimedia data from each of the input buffers <b>870</b>-<b>873</b> and writes the data to a set of multimedia tracks <b>880</b>-<b>883</b>. The multimedia data is subsequently read from each of the multimedia tracks <b>880</b>-<b>883</b> to a set of output buffers <b>890</b>-<b>893</b>, from which it is transmitted to one or more of the destination multimedia devices <b>150</b>, <b>151</b>, <b>163</b>. Buffering data streams on the home media server <b>110</b> in this manner provides significant cost efficiencies for the entire system. Specifically, because the multimedia data is buffered at a single distribution point within the home media network <b>140</b> (i.e., the home media server <b>110</b>), no buffering is required at each of the individual multimedia devices <b>150</b>, <b>151</b> and <b>160</b>-<b>166</b>, thereby significantly reducing the cost and complexity of these devices.

[0128] The mass storage device <b>230</b> of this embodiment has enough bandwidth in its read/write operations to support several multimedia streams at once. Although the seek time of the mass storage device <b>230</b> (i.e., the time required to jump from one track to another) may be relatively low (i.e., relative to its read/write bandwidth), buffering of the multimedia data in input and output buffers as described ensures that the various streams will be provided to their respective multimedia devices <b>150</b>, <b>151</b> and <b>160</b>-<b>166</b> without interruption.

[0129] In one embodiment, each of the multimedia streams <b>860</b>-<b>863</b> operate independently of one another. For example, if playback of a particular multimedia stream is paused, e.g., from multimedia device <b>150</b>, the home media server <b>110</b> will interrupt transmission of multimedia content from the output buffer <b>893</b> associated with that device <b>150</b>, and will begin storing subsequent, incoming multimedia content on the mass storage device <b>230</b> (e.g., within the media track <b>883</b>). However, this will not affect playback at any of the other multimedia devices on the network <b>140</b>. When playback is resumed, the content will be streamed from the output buffer <b>893</b> (and media track <b>883</b>) from the same point at which is was paused (thereby providing real time, time-shifting functionality for live, real-time broadcasts).

[0130] In one embodiment, an indexing module (not shown) will generate a content index for users of the home media server <b>110</b> which will provide users with a comprehensive, seamless listing of multimedia content from the Internet (e.g., streaming media content), broadcast channels (including live and pre-recorded broadcast channels), asynchronous/isochronous multimedia channels, and/or various other media sources/channels. Accordingly, this embodiment will provide users with the ability to navigate through and select content from a virtually unlimited number of different multimedia sources and channels having any knowledge of the underlying protocols and communication infrastructure supporting the sources/channels.

[0131] Intelligent Buffering and Bandwidth Allocation

[0132] Virtually all communication channels are bandwidth-limited in some manner, due to the physical limitations of the underlying transmission medium and/or the signaling limitations of the channel (e.g., the channel's allocated frequency spectrum). For example, a 100 Base-T Ethernet network is capable of providing a total data throughput of 100 Mbps, which is shared by all nodes (e.g., computers) on the network. Similarly, multimedia devices <b>150</b>, <b>151</b>; <b>160</b>-<b>166</b> communicating on the home media network <b>140</b> described above all share some maximum network signaling rate (e.g., if a standard IEEE 802.11b network is employed the signaling rate is 11 Mbps).

[0133] Because bandwidth is shared on these systems, overall network performance may degrade as a result of nodes performing concurrent, high-bandwidth network transactions. This can be particularly problematic on networks such as the home media network <b>140</b> which support real-time multimedia services. More specifically, high quality audio and video signals transmitted from the home media server <b>110</b> to multimedia nodes <b>150</b>, <b>151</b>, require some minimum level of network bandwidth to be rendered properly (i.e., without distortion or interruption). Accordingly, one embodiment of the invention includes intelligent buffering and bandwidth allocation techniques to ensure smooth playback of the multimedia signal at each of the multimedia nodes <b>150</b>, <b>151</b>.

[0134]FIG. 9<i>a </i>illustrates a histogram of normalized bitrate data for a particular multimedia stream (e.g., a DVD) over a period of 120 seconds. Curve <b>902</b> shows the bitrate averaged at one second intervals whereas curve <b>904</b> shows the bitrate averaged at <b>10</b> second intervals. The average bitrate over the entire <b>120</b> second interval is represented by curve <b>906</b> (approximately 4.7 Mbps). Accordingly, based on the histogram data, the effective bitrate required to properly render the video stream at multimedia node <b>150</b> fluctuates significantly—from a maximum throughput of 7.143 Mbps to a minimum throughput of 1.657 Mbps.

[0135] One embodiment of the home media server <b>110</b>, illustrated in FIG. 9<i>b, </i>uses this type of bitrate data to allocate bandwidth and buffering levels for multimedia playback. Accordingly, when a user selects audio or video content (e.g., a DVD) to be transmitted to a multimedia node (e.g., video node <b>151</b>), the home media server <b>110</b> initially retrieves a bitrate template <b>930</b> (e.g., a histogram of bitrate data) associated with the requested content from a bitrate database <b>935</b>. The database <b>935</b> may be maintained locally on the home media server <b>110</b> and/or, as illustrated, may be maintained on a remote database server <b>940</b> (e.g., maintained at the NOC <b>180</b>). In either case, the database <b>935</b> may be continually updated as new multimedia content becomes available. Once the bitrate template <b>930</b> is initially downloaded from the remote server <b>940</b>, a copy may be stored locally on the home media server <b>110</b> for future reference. In one particular embodiment, the bitrate template <b>930</b> may be transmitted along with the underlying multimedia signal (e.g., embedded within the MPEG-2 stream read from a DVD or broadcast over a cable channel), rather than maintained in a separate database <b>935</b>.

[0136] If the bitrate template <b>930</b> is maintained in a database <b>935</b>, various types of identification data <b>925</b> may be used to identify the correct template for the multimedia content being played including, but not limited to, those set forth in co-pending application entitled SYSTEM AND METHOD FOR SCALING A VIDEO SIGNAL, Ser. No. 09/632,458 (incorporated by reference above). For example, a checksum may be calculated for a known unique portion of the multimedia content and compared with checksums stored in the database <b>935</b>. Similarly, if the content is stored on a CD or DVD, the CD/DVD serial number (or other embedded identification code) may be used to perform a database <b>935</b> query. Various other identification techniques may be used to identify the multimedia content while still complying with the underlying principles of the invention. Once the correct bitrate template <b>930</b> is identified, it is transmitted from the remote server <b>940</b> to the home media server <b>110</b>. Alternatively, if the data is stored locally on the home media server <b>110</b>, it is retrieved directly from the home media server's storage device <b>230</b>.

[0137] In one embodiment, an allocation module <b>950</b> running on the home media server <b>110</b> analyzes the bitrate template <b>930</b> to establish an efficient bandwidth allocation and/or buffering policy for transmitting the multimedia stream(s). The allocation module <b>950</b> acts as a data “throttle,” increasing or decreasing the data throughput from the home media server <b>110</b> to the multimedia nodes <b>150</b>-<b>151</b> as necessary to meet the bitrate requirements of each multimedia stream (e.g., through control of the home media server output buffers <b>910</b>-<b>912</b> and/or RF transceiver <b>915</b>). The goals of one embodiment of the system are (1) to ensure that the underlying multimedia content is reproduced at the multimedia node <b>151</b> without interruption/jitter; (2) to minimize the memory requirements at the multimedia node <b>151</b>; (3) to minimize the playback delay experienced by the end user; and/or (4) to minimize the bandwidth required to accurately reproduce the multimedia content at the node <b>151</b>. Any of these goals, alone or in combination, may be factored into the allocation module's <b>150</b>'s bandwidth/buffering allocation policy.

[0138] In one embodiment, the allocation module <b>950</b> analyzes the bitrate template <b>930</b> to ensure that the amount of multimedia content in each multimedia node buffer—e.g., buffer <b>920</b> of multimedia node <b>151</b>—is sufficient to handle upcoming spikes. For example, given the bitrate template data set forth in FIG. 9<i>c, </i>the multimedia node buffer <b>920</b> must have sufficient multimedia data (i.e., an adequate number of bits) to handle the bitrate spike between 3 seconds and 4 seconds (i.e., 6.2 Mbps). As such, by analyzing the bitrate template <b>930</b> as a whole, the allocation module <b>950</b> may increase the allocated data throughput between 1 second and 3 seconds to sufficiently fill the buffer <b>920</b> by the time the bitrate spike arrives (i.e., at 3 seconds). Thus, the number of bits consumed during the spike (6.2 Meg) must be less than or equal to the number of bits in the buffer at start of spike period (3 seconds) minus the bits added to buffer during spike period (i.e., the per-second bitrate). Otherwise, playback of the multimedia stream will stall due to an underrun condition (i.e., a lack of multimedia data at the multimedia node <b>151</b>).

[0139] The allocation module <b>950</b> may also factor in bitrate templates <b>930</b> of other multimedia streams when making allocation decisions for a given stream. For example, when making allocation decisions for the DVD stream in FIG. 9<i>b </i>(which passes through buffers <b>910</b> and <b>920</b>), the allocation module <b>950</b> may evaluate the bitrate requirements of the other two streams (i.e., the MP3 stream and Cable stream passing through buffers <b>911</b>, <b>921</b> and <b>912</b>, <b>922</b>, respectively). As such, if one particular stream requires a significant amount of throughput at a given point in time, the allocation module will take anticipatory steps to ensure that sufficient multimedia data will be available. For example, in FIG. 9<i>d, </i>the bitrate data illustrated in timeline <b>960</b> indicates a severe bitrate spike between 40 and 60 seconds. The spike is severe enough that in order to properly render the multimedia stream associated with it, the allocation module <b>960</b> may need to fill the multimedia node buffer by the time the spike arrives (i.e., at 40 seconds) and also divert a significant amount of the system bandwidth to the stream to avoid an underrun condition. As such, in anticipation of the spike, the allocation module <b>950</b> may attempt to fill all the buffers on the system including the buffers of the other two streams (associated with the bitrate data shown in timelines <b>961</b> and <b>962</b>) so that by the time the spike arrives, it can divert bandwidth from these streams to the stream with the bitrate spike. It should be noted that the foregoing bandwidth/buffer allocation example was for the purpose of illustration only and should not be read to limit the scope of the invention.

[0140] In one embodiment, the when a new playback stream is requested at a multimedia node <b>151</b>, the allocation module <b>950</b> will initially allocate all system bandwidth available at that time to the stream. It will subsequently decrease the bandwidth (i.e., the “throttle”) only when other multimedia nodes require additional bandwidth and/or when the buffer at the multimedia node <b>151</b> fills up. Accordingly, one goal of this embodiment is to keep the buffer at the multimedia node <b>151</b> filled to its limit at all times (e.g., so that it will be ready for upcoming spikes).

[0141] Playback of the multimedia data from the multimedia node buffer <b>920</b> may start at different times, depending on the histogram data associated with the content. For example, the bitrate for certain high definition television broadcasts or DVDs such as the one illustrated in FIG. 9<i>e </i>(which shows bitrate data for the movie “South Park”) may start off at a relatively high value (i.e., approximately 8.6 Mbps). As such, it may be necessary to accumulate a certain amount of multimedia data in the multimedia node buffer <b>920</b> before initiating playback. The table <b>970</b> illustrated in FIG. 9<i>e </i>shows the amount of data that must be buffered before playback (column <b>972</b>), given a particular multimedia stream bitrate (column <b>971</b>). The table <b>970</b> also indicates the amount of time which a user must wait before playback begins (column <b>973</b>). As indicated in the bottom row of the table <b>970</b>, at a bitrate of 9 Mbps, no buffering of the multimedia signal is required. In one embodiment, playback is initiated by the allocation module <b>950</b> (as indicated by the control signal <b>952</b> in FIG. 9<i>b</i>).

[0142] In contrast to multimedia stream described by the histogram of FIG. 9<i>e, </i>the multimedia stream described by the histogram illustrated in FIG. 9<i>f </i>(the DVD for the movie “Species <b>1</b>”) requires significantly less buffering before playback. More particularly, as indicated in table <b>975</b>, no pre-playback buffering is required at a bitrate of 5 Mbps. As such, if 5 Mbps or more system bandwidth is available, playback may begin as soon as the stream reaches the multimedia node <b>151</b>. In addition, in one embodiment, the allocation module <b>950</b> may initially allocate more bandwidth than required to fill the multimedia node buffer <b>920</b> during playback (e.g., so that more system bandwidth may be allocated elsewhere once the buffer is full).

[0143] In one embodiment, when a new playback stream is requested from a multimedia node <b>151</b>, the allocation module <b>950</b> may initially allocate just enough system bandwidth to meet some minimum playback delay threshold. Thus, if this minimum delay threshold is set at 4.5 seconds, the allocation module <b>650</b> must allocate at least 7 Mbps to reproduce the multimedia content represented by the histogram of FIG. 9<i>e </i>(see Table <b>970</b>, 5^throw). By contrast, to meet the minimum delay threshold for the multimedia content represented by the histogram of FIG. 9<i>f, </i>the allocation module <b>950</b> may allocate a bitrate of less than 5 Mbps (see Table <b>975</b>). After the initial bandwidth allocation, the allocation module may use the histogram data to ensure that the amount of multimedia content in the multimedia node buffer <b>920</b> is sufficient to handle upcoming spikes in bitrate (as described above).

[0144] Various additional bitrate histograms and related bandwidth allocation tables are set forth in FIGS. 9<i>g </i>through <b>9</b><i>m. </i>It should be noted, however, that these histograms are provided merely for the purpose of illustration, and should not be read to limit the scope of the present invention. Moreover, although the examples set forth above focus on the reproduction of DVD movies at multimedia nodes on a home media network, it should be noted that the underlying principles of the invention may be implemented on virtually any system in which time-based data is transmitted over a bandwidth-limited network. Accordingly, the scope and spirit of the present invention should be judged in terms of the claims set forth below.

[0145] Conditional Access and Encryption

[0146] One embodiment of a cable broadcast module for receiving one or more broadcast channels is illustrated in FIG. 10. This embodiment includes two tuners <b>1010</b>, <b>1011</b> for concurrently tuning to two separate broadcast channels (e.g., to be viewed at two separate multimedia nodes on the home media network <b>140</b>). Additional tuners may be included within the cable broadcast module as necessary (i.e., for receiving additional broadcast channels).

[0147] In one embodiment of the system, a smartcard <b>330</b> (see also FIG. 3) inserted into one or more of the media modules <b>320</b>-<b>325</b> may be programmed with a specific set of access rights defining the particular channels to which users are permitted access. The smartcard <b>330</b> may work in conjunction with a conditional access module <b>1030</b>, which will prevent certain channels/content from being transmitted on the system which the user does not have the right to receive. In one embodiment, different members of a family may be assigned smartcards <b>330</b> with different access privileges. For example, children may be assigned smartcards <b>330</b> which limit the channels and/or Internet sites which they are permitted to access.

[0148] In the illustrated embodiment, the signal outputs from each of the tuners <b>1010</b>, <b>1011</b> are fed into separate audio and video analog-to-digital decoder modules <b>1024</b>, <b>1026</b> (audio) and <b>1023</b>, <b>1025</b> (video), respectively. In one embodiment, the signals are then re-encoded with a compression codec. For example, in the embodiment shown in FIG. 9, MPEG-2 encoder modules <b>1031</b>, <b>1033</b> encode the audio/video signals into MPEG-2 format (i.e., which may subsequently be decoded by any multimedia devices <b>150</b>, <b>151</b> on the home media network <b>140</b>). It should be noted that various other digital compression codecs may be used (e.g., AC-3, MPEG-1, . . . etc) while still complying with the underlying principles of the invention.

[0149] In addition, in one embodiment, before being transmitted onto the system bus <b>220</b>, the encoded multimedia signals are encrypted by an encryption module <b>1060</b> using a unique encryption key <b>1061</b>. As such, in this embodiment, all multimedia data stored on the home media server <b>110</b> (i.e., on the mass storage device <b>230</b>) and transmitted across the home media network <b>140</b> are encrypted, thereby preventing copying and playback by any unauthorized devices listening in one the network <b>140</b> or on the system bus <b>220</b>. Moreover, authorized multimedia devices <b>150</b>, <b>151</b>, <b>160</b>-<b>166</b> (i.e., those certified by the NOC <b>180</b>) communicating on the home media network <b>140</b> are configured with the same unique encryption key <b>1061</b>, thereby allowing them to properly decode the multimedia data transmitted from the home media server <b>110</b>.

[0150] In one embodiment, the encryption key <b>1061</b> is transmitted securely to the home media server <b>110</b> and media devices <b>150</b>, <b>151</b>; <b>160</b>-<b>166</b> through the conditional access system. Alternatively, or in addition, the key <b>1061</b> may be transmitted using conventional secure communication techniques such as Secure Sockets Layer (“SSL”) or Data Encryption Standard (“DES”).

[0151] One embodiment of a satellite module for connecting the home media server <b>110</b> over a satellite channel is illustrated in FIG. 11, including multiple tuners <b>1110</b>, <b>1111</b>; forward error correction modules <b>1130</b>, <b>1140</b>; a smartcard <b>1120</b> and associated conditional access module <b>1150</b>; and an encryption module <b>960</b> for encrypting content transmitted onto the system bus <b>220</b> (and across the home media network <b>140</b>). The different decoding, encryption, and authentication features described above with respect to the cable broadcast module illustrated in FIG. 9 are also configured into one embodiment of the satellite module.

[0152] One embodiment of a cable modem for connecting the home media server <b>110</b> over a cable channel is illustrated in FIG. 12. The cable modem includes a modulator unit <b>910</b>, a Data Over Cable Service Interface Specification (“DOCSIS”) module <b>920</b>, and a data pump/PCI interface unit <b>930</b>. Various different types of cable modems may be coupled to the home media server <b>110</b> while still complying with the underlying principles of the invention.

[0153] In addition to the encryption system described above, one embodiment of the system provides copyright protection through the use of copyright tags associated with content stored on the home media server <b>110</b>. The tags of this embodiment identify which types of content/information may be copied or streamed to which multimedia devices. As illustrated in FIG. 13, tags may be set to a variety of copy/playback levels, including, for example, a tag <b>1311</b> indicating no restrictions on copying for audio file <b>1310</b>; a tag <b>1321</b> allowing only a single serial copy (e.g., to a CD-RW disk) with no copying to personal computers for audio file <b>1320</b>; a tag <b>1331</b> permitting playback to local TVs (i.e., within the home media network <b>140</b>) for video file <b>1330</b>; and a tag <b>1341</b> allowing 24-hour playback to local TVs only (e.g., similar to a pay-per-view feature) for video file <b>1340</b>. Accordingly, this embodiment provides an additional mechanism for providing secure storage and transmission of copyrightable material. In one particular embodiment, content providers (e.g., cable and satellite providers) are provided with the ability to program tags into their content as necessary.

[0154] Local FM Broadcast

[0155] In one embodiment of the invention, the media server <b>110</b> or other type of multimedia recorder system is equipped with a radio transmitter for locally transmitting selected audio content at a specified carrier frequency to radio receivers distributed throughout the user's home (current FCC guidelines allow unregulated radio broadcast at or below <b>100</b>mW of power). This embodiment is illustrated generally in FIG. 14 which shows the multimedia recorder <b>1400</b> broadcasting stored audio content to a stereo receiver <b>1401</b>, an alarm clock radio <b>1402</b> and a portable AM/FM radio <b>1403</b>. One of the obvious benefits of this configuration is that it provides a relatively inexpensive mechanism for audio distribution by employing AM/FM receivers already owned by the user.

[0156]FIG. 15<i>a </i>illustrates a system architecture according to one embodiment of the invention. The recorded audio content <b>1505</b> is transmitted from the mass storage device to a decoder <b>1510</b> which decodes the audio content according to a specified decoding algorithm. The particular decoding algorithm employed by the decoder is based on the manner in which the audio content was originally encoded. For example, if the audio content <b>1505</b> was encoded using MPEG Audio Layer 3 (“MP3”) then the decoder <b>1510</b> is an MP3 decoder. Similarly, if the audio content <b>1505</b> was initially encoded using MPEG Advanced Audio Coding (“AAC”) then the decoder <b>1510</b> is an AAC decoder. It should be noted, however, that the underlying principles of the invention are not limited to any particular audio encoding format.

[0157] Once decoded, a modulator unit <b>1520</b> modulates the audio content using frequency modulation (“FM”) and/or amplitude modulation (“AM”). Following modulation, a transmitter <b>1530</b> transmits the modulated signal at a specified carrier frequency. In one embodiment, to avoid interference from nearby radio stations, the particular carrier frequency used by the transmitter <b>1530</b> is adjustable. The user may manually adjust the carrier frequency until he/she finds one with a minimum amount of interference. Alternatively, one embodiment of the invention will automatically search for a carrier frequency at which to transmit. This embodiment may be equipped with a tuner and/or signal strength detection circuitry to measure AM or FM signal strength values at prospective carrier frequencies.

[0158] A content selection module <b>1515</b> selects the particular audio content to be broadcast from the digital multimedia recorder. In one embodiment, the content selection module <b>1515</b> is implemented in software executed by a general purpose CPU. It should be noted, however, that the content selection module <b>1515</b>, as well as all of the other functional modules described herein, may be implemented in any combination of hardware and software while still complying with the underlying principles of the invention.

[0159] The content selected by the content selection module <b>1515</b> may include audio content from a variety of sources including, but not limited to, audio content copied from CDs and/or downloaded from the Internet (e.g., stored as an indexed audio “jukebox” on the mass storage device); AM/FM content, either currently being broadcast, or previously broadcast and recorded on the mass storage device; audio components of broadcast television programs; digitally sampled sound effects (e.g., waterfalls, rivers, thunderstorms, . . . etc); and/or telephone messages. Various alternate types of audio content may be stored consistent with the underlying principles of the invention.

[0160] As illustrated in FIG. 15<i>b, </i>additional decoders <b>1511</b>, modulators <b>1512</b> and transmitters <b>1531</b> may be employed to transmit audio content at different carrier frequencies. Thus, in this embodiment, a first set of audio content (e.g., the CD jukebox) may be transmitted at a first carrier frequency and a second set of audio content (e.g., time-shifted radio) may be transmitted at a second carrier frequency. Two (or more ) users could then concurrently listen to the first and second sets of audio content by tuning radios to the first and second carrier frequencies, respectively. Accordingly, the content selection module <b>1515</b> of this embodiment would be separately programmable by the two or more different users.

[0161] The content selection module <b>1515</b> may select audio content to be broadcast based on user inputs. For example, in one embodiment, the user may manually select content by navigating through a content selection menu with a remote control or other cursor control device. In addition, in one embodiment, the user may program the content selection module <b>1515</b> to broadcast specified audio content at specified dates/times. FIG. 16 illustrates an exemplary broadcast timer window <b>1600</b> in which the user enters timed broadcast selections. A first column is reserved for content selections <b>1601</b> and a second column is reserved for broadcast timing data <b>1602</b>. In the illustrated example, the user has selected an AM radio station <b>1610</b> (KCBS AM 770), a desired time period during which the radio station should be recorded <b>1611</b>, and a date setting <b>1612</b>, indicating that the recording should occur over the designated time period each day. Various alternate user selections may be provided for the date setting including, but not limited to, a standard date, “weekly recording,” “monthly recording,” . . . etc (i.e., indicating that the radio program should be recorded at the specified time each week, each month, . . . etc).

[0162] Under the broadcast timing heading <b>1602</b>, the user has indicated that the AM radio program recorded from 7:00 AM to 7:15 AM should be rebroadcast locally from 7:15 AM until 7:30 AM. Time shifting the radio broadcast in this manner may be particularly useful in combination with a standard alarm clock radio <b>1403</b> set to the appropriate local AM or FM carrier frequency. For example, if the user typically wakes up at 7:15 AM and sets the radio alarm to trigger at 7:15 AM, he/she can be awakened to the day's news headlines which are typically covered at the top of the hour. Similarly, if traffic reports are broadcast periodically at specified times throughout the hour the user can time-shift the traffic report to coincide with the time the user leaves for work. If the user's car is within range of the transmitter, he/she can then receive an instant traffic update. Referring again to FIG. 16, following the 15-minute time-shifted radio program from 7:00 to 7:15, the user has also programmed the system to play classical selections from the audio jukebox from 7:15 AM to 7:30 AM on a daily basis (as indicted in data fields <b>1613</b> and <b>1614</b>).

[0163] It should be noted that the specific details set forth above are used for the purpose of illustration only. Various additional and/or alternate local broadcast selections may be programmed within the content selection module <b>1515</b> while still complying with the underlying principles of the invention (e.g., broadcast new telephone messages following the news report; broadcast “while noise” sound effects such as a waterfall throughout the evening, . . . etc).

[0164] In one embodiment, radio program schedule data may be downloaded from a server and displayed for the user in the broadcast timer window <b>1600</b>. The program data may include, for example, the title of each radio program, the particular topic of each radio program, the host of the radio program, and/or a various additional program-related information.

[0165] One embodiment of the radio broadcast system may used in conjunction with MP3 players/recorders (or other type of digital audio recorders) equipped with radio tuners. For example, if the user's car is equipped with an MP3 player/recorder, the user can manage the audio content stored on the player/recorder by broadcasting new audio content from the multimedia recording system to the player/recorder. The user may either update the audio content manually (e.g., by hitting a “record” button on the player/recorder) or, if the player/recorder is equipped with a timer, the user may program the player/recorder to begin recording at a specified time each day, week, . . . etc, synchronized with a selected local radio broadcast.

[0166] In one embodiment of the invention, illustrated in FIG. 17, the modulator <b>1520</b> and/or the FM transmitter <b>1530</b> are combined together within an external broadcast apparatus <b>1700</b> (i.e., “external” in the sense that it is not physically included within the multimedia recorder apparatus <b>1720</b>). The broadcast apparatus <b>1700</b> is coupled to the multimedia recorder apparatus <b>1720</b> via an communications port <b>1710</b>. In one embodiment, the communications port is a Universal Serial Bus (“USB”) port (or a USB 2.0 port). In another embodiment, the communications port <b>1710</b> is a Firewire™ (IEEE 1394) port. However, the type of communications port <b>1710</b> employed in not pertinent to the underlying principles of the invention.

[0167] In the embodiment illustrated in FIG. 17, the external broadcast apparatus <b>1700</b> is comprised of a modulator <b>1520</b> and a transmitter <b>1530</b>. In an alternate embodiment, the multimedia recording apparatus <b>1700</b> may be configured with a modulator. As such, in this embodiment, the internal modulator is used to modulate the audio content and only the transmitter <b>1530</b> is provided in the external broadcast apparatus <b>1700</b>. Similarly, the decoder <b>1510</b> may be included within the external broadcast apparatus <b>1700</b> while still complying with the underlying principles of the invention.

[0168] Embodiments of the present invention include various steps, which have been described above. The steps may be embodied in machine-executable instructions which may be used to cause a general-purpose or special-purpose processor to perform the steps. Alternatively, these steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

[0169] Elements of the present invention may also be provided as a computer program product which may include a machine-readable medium having stored thereon instructions which may be used to program a computer (or other electronic device) to perform a process. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnet or optical cards, propagation media or other type of media/machine-readable medium suitable for storing electronic instructions. For example, the present invention may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).

[0170] Throughout the foregoing description, for the purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the present system and method. It will be apparent, however, to one skilled in the art that the system and method may be practiced without some of these specific details. Accordingly, the scope and spirit of the invention should be judged in terms of the claims which follow.