Method for using bluetooth module to process non-bluetooth signals

An electronic device having a communications module with a first set of data rates can be enabled to use the communications module to process signals received from a source that uses a second set of data rates. The device may generate packets, frames, etc. at the first set of data rates using the communications module from the signals received from the remote source by sampling signals at one or more of the first set of data rates. The device may then reconstruct data or payloads originally transmitted in the signals at the second set of data rates from the packets generated at the first set of data rates. Thus, the device can process signals or transmissions at the second set of data rates using the first set of data rates without requiring additional receivers or communications modules to process the signals.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is related to co-pending U.S. patent application Ser. No. 12/030,754, filed on Feb. 13, 2008 and entitled “Momentary Burst Protocol for Wireless Transmission,” the entire disclosure of which is herein incorporated by references for all purposes.

FIELD OF THE INVENTION

The present invention relates to communication protocols. More specifically, the present invention relates to techniques for using a communications module that processes data at a first data rate to process signals sent at a second data rate.

BACKGROUND OF THE INVENTION

Electronic devices, such as portable media players, cellular phones, personal digital assists (PDAs), and the like, are prevalent in today's marketplace, as are the peripheral electronic devices that support their use, such as docking stations and the like. As competition in the personal electronics marketplace becomes ever more heated, consumers have become more demanding in terms of both the functionality and use of such devices.

Often, increases in functionality also include the inclusion of additional circuitry to the device that provide the functionality. The additional circuitry adds to the size and expense of the device. Additionally, some circuitry may need to be included in a next generation device in order to provide backwards compatibility with previous functionality.

Accordingly, what is desired are improved methods and apparatus for providing some features of backwards compatibility without adding additional circuitry to a device. Additionally, what is desired are improved methods and apparatus for reducing some of the drawbacks discussed above.

BRIEF SUMMARY OF THE INVENTION

An electronic device having a communications module with a first set of data rates can be enabled to use the communications module to process signals received from a source that uses a second set of data rates. The device may generate packets, frames, etc. using the communications module from the signals received from the remote source by sampling the signals at one or more of the first set of data rates. The device may then reconstruct data or payloads originally transmitted in the signals at the second set of data rates from the packets generated at the first set of data rates. Thus, the device can process signals or transmissions at the second set of data rates using the first set of data rates without requiring additional receivers or communications modules to process the signals.

In various embodiments, a non-Bluetooth transmitter communicates data by generating a non-Bluetooth packet. The non-Bluetooth transmitter may transmit the non-Bluetooth packet at a particular data rate, for example, using a unicast, multicast, anycast, or broadcast transmission. A Bluetooth receiver, such as a portable media player or smart phone with Bluetooth circuitry, can receive the non-Bluetooth signals sent at the particular data rate using the Bluetooth circuitry. In one embodiment, the Bluetooth receiver can “over-sample” the signal or transmission of the non-Bluetooth packet sent at the particular data rate using one or more data rates associated with the Bluetooth circuitry.

In some embodiments, the Bluetooth receiver may generate a Bluetooth packet from the over-sampled information. The Bluetooth receiver may reconstruct the non-Bluetooth packet from the over-sampled information. The Bluetooth receiver may further interpret portions of the reconstructed non-Bluetooth packet according to the Bluetooth protocol, for example, to ensure proper security and addressing.

In still further embodiments, the electronic device may manage communications between signals at the first and second data rates. The device may prioritize communications (e.g., transmissions and/or receptions) in response to policies, timing plans, frequencies, or the like. In one embodiment, the device may manage communications that may occur on a determined frequency, such that interference and overlap may be reduced.

A further understanding of the nature and the advantages of the inventions disclosed herein may be realized by reference of the remaining portions of the specification and the attached drawings.

DETAILED DESCRIPTION OF THE INVENTION

In order to better understand the present invention, aspects of the environment within which various embodiments operate will first be described.

FIG. 1is a block diagram of media player100that may incorporate embodiments of the present invention. In general, a media player stores content and/or media assets, such as audio tracks, movies, or photos that can be played or displayed on the media player. One example of media player100can be the iPod® media player, which is available from Apple, Inc. of Cupertino, Calif. Another example of media player100can be a personal computer, such as a laptop or desktop.

In this example, media player100includes processor110, storage120, user interface130, and communications interface140. In general, processor110controls various functionalities associated with media player110. Media play100may output audio content, video content, image content, and the like. Media player100may further output information associated with content, such as track information and album art.

Typically, a user may load or store content using storage120. Storage120may be any read-only memory (ROM), random access memory (RAM), non-volatile memory, flash memory, floppy disk, hard disk, and the like. A user may interact with user interface130of media player100to view or consume content. Some examples of user interface130are buttons, click wheels, touch pads, displays, touch screens, and other input/output devices.

Media player100typically includes one or more connectors or ports that can be used to load content, retrieve content, interact with applications running on media player100, interface with external devices, and the like. In this example, media player100includes communications interface140. Some examples of communications interface140include universal serial bus (USB) interfaces, IEEE 1394 (or FireWire/iLink®) interfaces, universal asynchronous receiver/transmitters (UARTs), wired and wireless network interfaces, transceivers, and the like. Media player100may connect to devices, accessories, private and public communications networks, such as the Internet and the like using communications interface140.

In one example, a connector or port may enable media player100to output audio to a pair of speakers150. In another example, a connector or port may enable media player to output audio to a pair of headphones160. In yet another example, a connector or port may enable media player100to interface with an accessory170, a host computer180, or be inserted into a docking system190.

Docking system190may further enable one or more accessory devices195to interface with media player100. There are today many different types of accessory devices170and195that can interconnect to media player100. For example, an accessory may allow a remote control to wirelessly control media player100. As another example, an automobile may include a connector into which media player100may be inserted such that an automobile media system can interact with media player100, thereby allowing media content stored on media player100to be played within the automobile.

Often, media player100receives content or other media assets from a computer system (e.g., host computer160) that serves to enable a user to manage media assets. As an example, communications interface140allows media player100to interface with host computer160. Host computer160executes a media management application to manage media assets, such as loading songs, movies, photos, and the like onto media player100and creating playlists. One example of a media management application can be iTunes®, produced by Apple, Inc. of Cupertino, Calif.

In various embodiments, media player100includes a communications module with a first set of data rates can be enabled to use the communications module to process signals received from a source that uses a second set of data rates. Media player100may generate packets, frames, etc. using the communications module from the signals received from the remote source by sampling the signals at one or more of the first set of data rates. Media player100may then reconstruct data or payloads originally transmitted in the signals at the second set of data rates from the packets generated at the first set of data rates.

FIGS. 2A and 2Bare block diagram of transmitting device210and receiving device220in one embodiment according to the present invention. In various embodiments, media player100can be transmitting device210and configured to transmit data. Media player100may also be receiving device220, and configured to receive data.

In this example, transmitting device210includes transmitter230and antenna240. Transmitter230can be any hardware and/or software elements configured to transmit data. Transmitter230may include a radio configured to transmit data wirelessly via antenna240using a number of formats or protocols. Transmitter230may communicate data using one or more predetermined data rates. Some examples of protocols may be IEEE 802.11 or WiFi, IEEE 802.15 or Bluetooth, IEEE 802.16 or WiMAX, CDMA, GSM, or other wired and wireless protocols. Some examples of transmitting device210may be media player100acting as a transmitter, a wireless remote control, a remote sensor, a wireless accessory, or the like.

Receiving device220includes receiver250and antenna260. Receiver250can be any hardware and/or software elements configured to receive data. Receiver250may include a radio configured to receive data wirelessly via antenna260using a number of formats or protocols, such as those discussed above. Receiving device220may communicate data using one or more predetermined data rates. Some examples of receiving device250may be media player100acting as a receiver, a wireless accessory, and the like.

In various embodiments, receiving device220may process signals normally at a first set of data rates. Receiving device220may further process signals received from a source that uses a second set of data rates. Receiving device220may generate packets, frames, etc. from the signals at the second set of data rates received from the source by sampling the signals as if received using the first set of data rates. Receiving device220may then reconstruct data or payloads originally transmitted in the signals at the second set of data rates from the packets generated at the first set of data rates. For example, receiving device220may be configured to process non-Bluetooth signals received from a remote source (e.g., transmitting device210embodied as a remote sensor, transponder, etc.) using a Bluetooth module.

FIG. 3is a block diagram of Bluetooth device300in one embodiment according to the present invention. Bluetooth device300includes processor310, memory320, Bluetooth module330, antenna340, and bus350. Processor310, memory320, and Bluetooth module330are link via bus350. Bluetooth module330is linked to antenna340.

Bluetooth module330can be any hardware and/or software elements configured to communicate data (e.g., transmit and/or receive) using one or more of wired and/or wireless protocols. One example of Bluetooth module330is described further with respect toFIG. 4.

FIG. 4is a block diagram of Bluetooth module330in one embodiment according to the present invention. Bluetooth module330includes Bluetooth circuitry405and radio410. Bluetooth circuitry405can be any hardware and/or software elements for communicating data. Bluetooth circuitry405may communicate data using one or more first data rates.

In various embodiments, Bluetooth circuitry405may use the one or more first data rates to process data sent from a transmitter using or more second data rates. For example, Bluetooth circuitry405may primarily communicate data using the Bluetooth protocol, and secondarily process data from one or more non-Bluetooth protocols.

In this example, Bluetooth circuitry405includes Logical Link Control and Adaptation Protocol (L2CAP) layer415, Host Control Interface (HCI)420, Link Manager layer425, Baseband layer430, and Radio layer435. L2CAP layer415can be any hardware and/or software elements configured to provide connection-oriented and connectionless data services. L2CAP layer415may further provide protocol multiplexing capabilities, segmentation and reassembly operations, and group abstractions. In various embodiments, two link types are supported: Synchronous Connection-Oriented (SCO) links (e.g., which support real-time voice traffic using reserved bandwidth) and Asynchronous Connection-Less (ACL) links (e.g., which support best effort traffic).

HCI420can be any hardware and/or software elements configured to provide one or more command interfaces to Link Manager layer425and Baseband layer430. HCI layer420may provide access to hardware status and control registers associated with Bluetooth circuitry405. In various embodiments, HCI420may provide a uniform method of accessing Bluetooth and non-Bluetooth baseband capabilities, such as processing non-Bluetooth signals, managing Bluetooth and non-Bluetooth communications, or the like.

Link Manager layer425can be any hardware and/or software elements configured to provide link management. Link Manager layer425may provide link setup, authentication, link configuration, and other protocols. In some embodiments, Link Manager layer425may discover other remote link managers and communicate with them via the Link Manager Protocol (LMP). In general, the Link Manager Protocol essentially consists of a number of protocol Data Units (PDUs), which are sent from one device to another.

Baseband layer430can be any hardware and/or software elements configured to provide management of physical channels and links. Baseband layer430may include a Link Controller, which works with Link Manager layer425for carrying out link level routines, such as link connection and power control. In various embodiments, Baseband layer430may manage asynchronous and synchronous links, handle packets, and perform paging and inquiry to access and inquire Bluetooth devices in the area. Baseband layer430may include a baseband transceiver that applies a time-division duplex (TDD) scheme (alternate transmit and receive), thus, time may be also slotted apart from different hopping frequency (frequency division).

Radio layer435can be any hardware and/or software configured to provide the requirements of a Bluetooth transceiver device using one or more predetermined frequencies, such as operating in the 2.4 GHz ISM band.

In one example of operation, Bluetooth module330can receive control signals using control lines445to operate one or more functionalities associated with Bluetooth circuitry405and radio410. Bluetooth module330can receive or provide data using data lines445. Bluetooth module330may be linked to antenna340via line450through which radio410transmits and/or receives signals.

Returning again toFIG. 3, in various embodiments, Bluetooth module330may be configured to process packets, signals, frames, or the like using the Bluetooth protocol for wireless personal area networks (PANs). Additionally, Bluetooth module330may process one or more types of non-Bluetooth signals. Thus, Bluetooth device300may process Bluetooth signals as well as non-Bluetooth signals. Bluetooth module300may be programmed to simultaneously handle both Bluetooth and non-Bluetooth communications. In one example, a transponder may transmit data using a non-Bluetooth protocol. Bluetooth module330may receive or “sample” (e.g., using hardware, software, firmware, or combinations thereof) the non-Bluetooth signals transmitted by the radio.

In some embodiments, Bluetooth module330may process data at one or more data rates associated with the Bluetooth protocol. Bluetooth module330may “over-sample” non-Bluetooth signals using a data rate of the Bluetooth protocol (e.g., 1 Mbps) that is different from the data rate of the non-Bluetooth protocol (e.g., 250 kbps) with which the data was sent. In one example, Bluetooth module330samples the non-Bluetooth signals at a data rate that is an order of a magnitude greater that the data rate with which the non-Bluetooth signals were sent.

In response to sampling the non-Bluetooth signals, Bluetooth module330then may reconstruct the originally transmitted data. For example, one or more Bluetooth packets may be generated using the above over-sampling. Bluetooth module330may reconstruct any data or payloads carried in the original non-Bluetooth signals from the newly generated Bluetooth packets. Bluetooth module330may interpret portions of the Bluetooth packets (or the reconstructed non-Bluetooth packets) according to the Bluetooth protocol, for example, to provide error correction, ensure device security, addressing, or the like.

In still further embodiments, Bluetooth module330may manage communications between Bluetooth and non-Bluetooth signals. Bluetooth module330may prioritize transmissions and/or scheduled receptions in response to timing plans associated with non-Bluetooth signals from remote sources. In one embodiment, Bluetooth module330may determine a frequency associated with transmission of non-Bluetooth signals. Bluetooth module330then may manage scheduling and/or prioritization of communications (e.g., both Bluetooth and non-Bluetooth) associated with the determined frequency, such that interference, conflicts, and overlap may be reduced.

Accordingly, Bluetooth device300may not need to include any receivers in addition to Bluetooth module330to process both Bluetooth and non-Bluetooth signals.

FIG. 5is a flowchart of a method for processing data transmitted using a first protocol in one embodiment according to the present invention. The processing depicted inFIG. 5may be performed by software modules (e.g., instructions or code) executed by a processor of a computer system, by hardware modules of the computer system, or combinations thereof.FIG. 5begins in step500.

In step510, data is received. For example, a remote source may collect data and send data to a transmitter to be transmitted to a remote destination. In step520, a non-Bluetooth packet is generated based on the data. Non-Bluetooth packets can be any transmissions, signals, frames, packets or the like, that do not use the Bluetooth protocol to transmit data.

In step530, the non-Bluetooth packet is transmitted using a non-Bluetooth protocol. For example, the data may be included is a payload of a sensor packet. The sensor packet then may be transmitted according to any number of non-Bluetooth protocols. In another example, the data may be transmitted at a different data rate than the Bluetooth protocol.

In step540, transmission of the non-Bluetooth packet is received. In one embodiment, a transmission of the non-Bluetooth packet is sampled by a Bluetooth module (e.g., Bluetooth module330). For example, Bluetooth module330receives the transmission of the non-Bluetooth packet using a first data rate (e.g., 1 Mbps) associated with the Bluetooth protocol. If the transmission of the non-Bluetooth packet occurs at a second data rate that is different from (e.g., lower than) the first data rate associated with the Bluetooth protocol, Bluetooth module330may “over-sample” the transmission of the non-Bluetooth packet. In general, over-sampling using the data rate associated with the Bluetooth protocol provides a plurality of data elements (or samples) at the Bluetooth data rate for each individual data element of the transmission of the non-Bluetooth packet at the non-Bluetooth data rate.

In step550, a Bluetooth packet is generated in response to receiving the non-Bluetooth packet. For example, Bluetooth module330may generate the Bluetooth packet from the plurality of data elements received at the Bluetooth data rate representing the individual data elements of the non-Bluetooth signal. In step560, the non-Bluetooth packet is reconstructed from the Bluetooth packet. In one example, Bluetooth module330includes hardware, software, and/or firmware that interprets, filters, or the like the Bluetooth packet into the non-Bluetooth packet. Bluetooth module330may generate a replica of the non-Bluetooth packet or reformat the Bluetooth packet to include reconstructed portions (e.g., headers, addresses, payloads, etc.) of the non-Bluetooth packet.

In step570, the data is output. In some embodiments, Bluetooth module330outputs the payload of the reconstructed non-Bluetooth packet. In further embodiments, Bluetooth module330outputs a Bluetooth packet that includes reconstructed portions of the non-Bluetooth packet.FIG. 5ends in step580.

FIG. 6is a message sequence chart illustrating processing non-Bluetooth packets using a Bluetooth module (e.g., Bluetooth module330) in one embodiment according to the present invention. In this example, device210generates sensor data in step610. In step620, device210transmits the sensor data in packet630using the non-Bluetooth protocol. In order to transmit the data in packet630, device210may generate the non-Bluetooth packet and insert the data into a payload of the non-Bluetooth packet.

Referring toFIG. 7, packet700typically includes header710, body720, and tail730. Header710, body720, and tail730may include information, addresses, attributes, flags, and the like that define or indicate one or more features of the non-Bluetooth protocol. Body720generally includes data to be transmitted. The non-Bluetooth protocol may transmit packet700using a 250 kbps data rate.

Returning toFIG. 6, in step640, device220over-samples transmission of packet630using a Bluetooth module. Device220may generate a Bluetooth packet in response to receiving transmission of packet630that includes the over-sampled information. For example, data740ofFIG. 7includes a sequence of bits (e.g., 01 0111 00 10) in body730of packet700. Since a Bluetooth module typically processes data at 1 Mbps or faster, the Bluetooth module over-samples transmission of packet630to generate data750inFIG. 7. In this example, data750includes a sequence of bits (e.g., 0000 1111 0000 1111 1111 1111 0000 0000 1111 0000) representing the information in packet630over-sampled at approximately a four to one ratio (1 Mbps/250 kbps) to that of data740.

Thus, if device210transmits the value of one at 250 kbps, device220using a Bluetooth module processing data at 1 Mbps would “see” the value of one transmitted by device210as four values of one according to the Bluetooth protocol. Therefore, device220generates a Bluetooth packet that in fact includes four times as many bits as packet630. In various embodiments, device220may take advantage of this over-sampling for the purposes of error correction.

In step650, device220reconstructs packet630. For example, device220may apply one or more rules and/or filters to reconstruct packet630from the over-sampled information to obtain data760ofFIG. 7.

In step660, device220interprets portions of packet630. For example, portions of packet630may be interpreted as a Bluetooth source address, destination address, attribute, checksum, and the like. Typically, Bluetooth radios are constructed to be programmed to lock onto a very particular bit sequence (or access code) at the beginning of a transmission. Transmissions not having a particular bit sequence may be discarded by the Bluetooth radio. In various embodiments, portions of packet630may be interpreted as a Bluetooth access code, allowing the non-Bluetooth transmitter to transmit data that will be accepted by the Bluetooth radio.

In step670, device220obtains the sensor data. Device220may retrieve the sensor data from the body portion of packet630.FIG. 6ends in step670.

FIG. 8is a flowchart of a method for processing non-Bluetooth packets in one embodiment according to the present invention.FIG. 8begins in step800.

In step810, a Bluetooth packet is received. In step820, a non-Bluetooth packet is reconstructed from the Bluetooth packet. For example, as discussed above, transmission of a non-Bluetooth packet may be received by a Bluetooth module (e.g., over-sampled) to generate the Bluetooth packet. Hardware, software, and/or firmware elements of the Bluetooth module may apply rules, filters, and other algorithms to the Bluetooth packet to reconstruct the non-Bluetooth packet.

If the non-Bluetooth packet includes a valid cyclic redundancy check (CRC) in step830, a determination is made in step840whether the non-Bluetooth packet includes a valid access code. If the non-Bluetooth packet does not include a valid CRC in step830, or does not include a valid access code in step840, the packet is dropped.

Alternatively, if the non-Bluetooth packet includes a valid access code, in step850, the payload of the non-Bluetooth packet is outputted (e.g., stored, sent to an operating system, or sent to an application).FIG. 8ends in step860.

In various embodiments, Bluetooth module330ofFIG. 3may be configured to process communications that coexist in both time and frequency. In general, transmissions or signals of non-Bluetooth packets can be used to send unscheduled communications. Because transmission of a packet may occur at any time, packets may be marked with information that indicates when a next packet will arrive. This can be generally called the timing plan. Bluetooth module330may use timing plan to internally prioritize communications.

FIG. 9is a flowchart of a method for managing communications in one embodiment according to the present invention.FIG. 9begins in step900.

In step910, a set of policies is received. For example, Bluetooth module330ofFIG. 3may receive a policy indicative of one or more criteria that need to be satisfied. The policy may also define an action to be performed when the one or more criteria are satisfied. In some embodiments, Bluetooth module330receives a set of policies that may prioritize voice traffic and communications over data traffic and communications. Bluetooth module330may receive a set of policies that prioritize communication to and from a first device (e.g., a headset) different from communication to and from a second device (e.g., a transponder or beacon).

In step920, a communication schedule associated with first protocol signals is determined. For example, timing and frequencies used by the first protocol signals may be determined. In step930, a communication schedule associated with second protocol signals is determined.

In step940, communications associated with the first protocol signals and the second protocol signals are managed. In one example, if Bluetooth module330knows when to expect the next Bluetooth or non-Bluetooth packet from device or transponder, Bluetooth module330may determine a schedule that allows Bluetooth module330to be free (e.g., both in time and/or frequency) to listen for the next packet. Bluetooth module330may schedule pending transmissions at intervals other than when the expected packet is to be received or ignore the expected packet to transmit data at a higher priority.

Additionally, Bluetooth communications may be designed to operate in noisy radio frequency environments, and use a fast acknowledgement and frequency-hopping scheme to make the link robust, communication-wise. In various embodiments, Bluetooth module330manages communications to avoid interference from other signals by hopping to a new frequency after transmitting or receiving a packet.

FIG. 10is a message sequence chart illustrating communications management in one embodiment according to the present invention. In this example, device1002communicates with device1004and device1006. Device1002can be any device that includes Bluetooth circuitry. For example, device1002may be a media player, a personal digital assistant, a smart phone, a Bluetooth dangle, or the like. Device1004and device1006can be any devices that communicate with device1002using one or more communications protocols, such as Bluetooth and non-Bluetooth protocols.

Referring toFIG. 10, in step1010, device1002receives one or more policies. The policies may be established by the manufacturer of device1002, a developer of hardware, software, and/or firmware elements of device1002, a user of device1002, or the like.

In step1015, device1004generates a non-Bluetooth signal. Device1006transmits non-Bluetooth signal1020, which is received by device1002. For example, device1002may receive the non-Bluetooth signal with a Bluetooth Module using one or more of the method discussed above. In step1025, device1002determines a timing plan and frequency associated with the non-Bluetooth signal. Device1002may determine when the next scheduled transmission of communications from device1004may occur. Device1002may further determine the frequency or frequencies that communications from device1004may use.

In step1030, device1002receives a Bluetooth packet address to device1006. For example, an application executing on device1002instruct device1002to send data to device1006. In step1035, device1002determines whether to transmit the Bluetooth packet based on the policies received in step1010.

If device1002determines in step1040to transmit the Bluetooth packet based on the policies, Bluetooth packet1045is transmitted to device1006. For example, a set of policies may indicate that voice communications are provided a higher quality of service than data communications. Therefore, if device1006is a wireless headset associated with device1002, device1002may prioritize communications with the wireless headset over other non-voice or non-headset specific communications.

In step1040, device1002may determine to not transmit the Bluetooth packet to device1006based on the policies. For example, device1002may determine that transmission of the Bluetooth packet can be delayed while device1002receives non-Bluetooth packet1050from device1004. Device1002may expect non-Bluetooth packet1050according to the determined timing plan, and schedule other communications around the expected receive windows. In step1055, device1002then transmits Bluetooth packet1060to device1006after receiving expected transmissions according to the determined timing plan.

In some embodiments, device1002may prioritize which frequencies may be used or reserved for communications. For example, device1002may reserve a particular frequency for reception of communications from device1004. Device1002then may only engage in communications with device1006on frequencies other than the particular frequency. In various embodiments, device1002may communicate such a preference to device1006to manage communications.

FIG. 11is a simplified block diagram of a computer system1100that may incorporate embodiments of the present invention.FIG. 11is merely illustrative of an embodiment incorporating the present invention and does not limit the scope of the invention as recited in the claims. One of ordinary skill in the art would recognize other variations, modifications, and alternatives.

In one embodiment, computer system1100includes processor(s)1110, random access memory (RAM)1120, disk drive1130, input device(s)1140, output device(s)1150, display1160, communications interface(s)1170, and a system bus1180interconnecting the above components. Other components, such as file systems, storage disks, read only memory (ROM), cache memory, codes, and the like may be present.

RAM1120and disk drive1130are examples of tangible media configured to store data such as audio, image, and movie files, operating system code, embodiments of the present invention, including executable computer code, human readable code, or the like. Other types of tangible media include floppy disks, removable hard disks, optical storage media such as CD-ROMS, DVDs and bar codes, semiconductor memories such as flash memories, read-only-memories (ROMS), battery-backed volatile memories, networked storage devices, and the like.

In various embodiments, input device1140is typically embodied as a computer mouse, a trackball, a track pad, a joystick, a wireless remote, a drawing tablet, a voice command system, an eye tracking system, a multi-touch interface, a scroll wheel, a click wheel, a touch screen, an FM/TV tuner, audio/video inputs, and the like. Input device1140may allow a user to select objects, icons, text, and the like, via a command such as a click of a button or the like. In various embodiments, output device1150is typically embodied as a display, a printer, a force-feedback mechanism, an audio output, a video component output, and the like. Display1160may include a CRT display, an LCD display, a Plasma display, and the like.

Embodiments of communications interface1170may include computer interfaces, such as include an Ethernet card, a modem (telephone, satellite, cable, ISDN), (asynchronous) digital subscriber line (DSL) unit, FireWire interface, USB interface, and the like. For example, these computer interfaces may be coupled to a computer network1190, to a FireWire bus, or the like. In other embodiments, these computer interfaces may be physically integrated on the motherboard or system board of computer system1100, and may be a software program, or the like.

In various embodiments, computer system1100may also include software that enables communications over a network such as the HTTP, TCP/IP, RTP/RTSP protocols, and the like. In alternative embodiments of the present invention, other communications software and transfer protocols may also be used, for example IPX, UDP or the like.

In various embodiments, computer system1100may also include an operating system, such as Microsoft Windows®, Linux®, Mac OS X®, real-time operating systems (RTOSs), open source and proprietary OSs, and the like.

FIG. 11is representative of a media player and/or computer system capable of embodying the present invention. It will be readily apparent to one of ordinary skill in the art that many other hardware and software configurations are suitable for use with the present invention. For example, the media player may be a desktop, portable, rack-mounted or tablet configuration. Additionally, the media player may be a series of networked computers. Moreover, the media player may be a mobile device, an embedded device, a personal digital assistant, a smart phone, and the like. In still other embodiments, the techniques described above may be implemented upon a chip or an auxiliary processing board.

The present invention can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium as a plurality of instructions adapted to direct an information-processing device to perform a set of steps disclosed in embodiments of the present invention. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the present invention.