Arbiter module

This application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Application Ser. No. 60/946,508, filed on Jun. 27, 2007, the entire disclosure of which is hereby incorporated by reference.

The subject matter of this patent application relates to arbitration of data.

Computers may include a variety of different types of devices, which may be used to provide the core functionality of the computer as well as to expand the functionality available from the computer. For example, the computer may include a processor and memory that are operable to execute instructions, such as an operating system, productivity application, and so on. The computer may also include additional devices to expand on this functionality, such as one or more input devices, display devices, and a variety of peripheral devices, such as printers, scanners, additional hard disk drives, and so on. However, each of these devices may consume a significant amount of power when placed in an active mode (e.g., ready to provide corresponding functionality), even when the device is not being used.

An arbiter module is described. In one or more implementations, an apparatus comprises a plurality of interfaces to provide a communicative coupling between a central processing unit, a media drive and a network. The apparatus further comprises one or more modules to manage data routing between each of the plurality of interfaces such that the data is routable between the media drive and the network independent of the central processing unit.

In one or more implementations, an arbiter module detects that a stream of data is to be routed between a network and a media drive without being routed through a central processing unit. An indication indicates that the central processing unit is permitted to sleep and at least a portion of the stream of data is routed between the network and the media drive.

In one or more implementations, a system comprises a central processing unit and means for managing routing of data between each of a plurality of interfaces such that the data is routable between a media drive connected to one of the plurality of interfaces and a network connected to another one of the plurality of interfaces while the central processing unit is asleep.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different instances in the description and the figures may indicate similar or identical items.

FIG. 1 is an illustration of an example operating environment that is configured to employ one or more arbitration techniques.

FIG. 2 is an illustration of a system in an example implementation in which an arbiter module of FIG. 1 is shown in greater detail.

FIG. 3 is an illustration of a system in an example implementation in which the arbiter module of FIGS. 1 and 2 is shown as being implemented with a central processing unit on a motherboard.

FIG. 4 is a flow diagram that depicts a procedure in an example implementation in which routing of data between a network and a media drive is managed by an arbiter module.

FIGS. 5-12 illustrate some examples of various devices that can each be implemented as a device that employs re-encryption techniques.

Overview

Traditional computers, such as desktop personal computers, laptop computers, mobile computers (e.g., mobile phones and personal digital assistants), game consoles, set-top boxes, and so on employed a central processing unit (CPU) architecture in which the CPU was involved in transferring data between a media drive and a network. Downloading a file from a network to be stored on a hard disk drive using this traditional CPU architecture, for instance, kept the CPU active for the entire download process even though the CPU may not be involved for significant portions of the process. Likewise, uploading a file from the hard disk drive to the network resulted in similar involvement by the CPU. Therefore, a significant amount of power may be consumed in these traditional CPU architectures by keeping the CPU (and other devices) in an active state in that the CPU is ready to perform operations but is not actively doing so.

An arbiter module is described. In an implementation, an arbiter module arbitrates communication between a network interface, a media drive interface, and a CPU. Additionally, communication may be performed by the arbiter module between the media drive interface and the network interface independently of the CPU. Thus, the CPU and other devices that are not actively involved in the communication between the media drive in the network may be put to sleep, thereby conserving power and complying with “green” considerations in mobile and non-mobile devices.

The arbiter module may be configured in a variety of ways. In an implementation, the arbiter module is configured with a processor to execute software. The software may be utilized to provide a variety of functionality in addition to the power consumption functionality previously described, such as to provide security for a computer that employs the arbiter module. For example, the software may include virus scan functionality such that data received via a network is scanned by the arbiter module before receipt by the CPU. Thus, the arbiter module may detect a virus before receipt by the CPU and/or the rest of the computer, e.g., the media drive, memory, and so on. A variety of other examples are also contemplated, further discussion of which may be found in relation to the following discussion.

In the discussion that follows, example operating environments are described that may incorporate arbiter module techniques. Example procedures are also described that may be employed in the example operating environments, as well as other environments. Thus, in instances in the discussion of the example procedures, reference will be made to the example environments by way of example. Accordingly, implementation of the example procedures is not limited to the example environments.

Operating Environment

FIG. 1 illustrates an example operating environment 100 that is configured to employ one or more arbiter module techniques. The illustrated operating environment 100 includes a computer 102 having a media drive 104 , a central processing unit (CPU) 106 and an arbiter module 108 . The arbiter module 108 is illustrated as providing a communicative coupling between the media drive 104 , the central processing unit 106 , and a network 110 .

The computer 102 may be configured in a variety of ways. For example, the computer 102 may be configured as a computing device that is capable of communicating over the network 110 , such as a desktop computer, a mobile station, an entertainment appliance, a set-top box communicatively coupled to a display device, a wireless phone, a game console, and so forth. Thus, the computer 102 may range from a full resource device with substantial memory, processor and power resources (e.g., personal computers, game consoles) to a low-resource device with limited memory, processing and/or power resources (e.g., wireless phones and personal digital assistants that use a battery).

The media drive 104 is illustrated as having media that is computer readable and/or computer writeable to store data. Accordingly, the media drive 104 may also assume a wide variety of configurations, such as a hard disk drive, a writeable and/or re-writeable optical disc drive, a removable-memory device, a flash drive (e.g., a “thumb” drive), and so on.

The CPU 106 may represent one or more CPUs, which are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, CPU 106 may be comprised of semiconductor(s) and/or transistors (e.g., electronic integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically-executable instructions. Alternatively, the mechanisms of or for CPUs to perform processing, and thus of or for the computer 102 , may include, but are not limited to, quantum computing, optical computing, mechanical computing (e.g., using nanotechnology), and so forth.

The arbiter module 108 is illustrated as being communicatively coupled to the media drive 104 , the CPU 106 , and the network 110 . Additionally, the arbiter module 108 is illustrated as “between” the central processing unit 106 and the media drive 104 as well as between the CPU 106 and the network 110 . Thus, as illustrated in FIG. 1 , data that is to be communicated from the network 110 to the CPU 106 is first passed through the arbiter module 108 and vice versa. Likewise, data to be communicated from the media drive 104 to the CPU 106 is first passed through the arbiter module 108 and vice versa.

In an implementation, the arbiter module 108 is representative of functionality of the computer 102 to route data between the network 110 and the media drive 104 independently of the CPU 106 . As previously described, traditional CPU architectures were configured such that the CPU was involved (even minimally) in the routing of data between a media drive and a network. However, minimal involvement involved keeping the CPU in an active state under traditional CPU architectures. Thus, the CPU actively consumed power even when not in use.

In the illustrated implementation, however, data may be communicated between the media drive 104 and the network 110 by the arbiter module 108 independently of the CPU 106 . The separation of the data communication between a media drive 104 and the network 110 from the CPU 106 (and other devices that may be connected to the CPU 106 ) may be used to support a variety of different functionality, further discussion of which may be found in relation to the following figure.

FIG. 2 depicts a system 200 in an example implementation in which the arbiter module 108 of FIG. 1 is shown in greater detail. The arbiter module 108 is illustrated as being communicatively coupled to a packet-switched network 202 . Packet-switched network 202 may or may not correspond to the network 110 of FIG. 1 and therefore implementation of network 110 is not limited to a packet-switched network 202 as shown in FIG. 2 . The packet-switched network 202 may assume a variety of configurations, such as an Ethernet network 204 and the Internet 206 as illustrated, and may be implemented using wired or wireless techniques.

The arbiter module 108 of FIG. 2 is illustrated as including a power consumption module 208 and a security module 210 . The power consumption module 208 is representative of functionality of the arbiter module 108 to manage power consumption of the computer 102 of FIG. 1 . As previously described in relation to FIG. 1 , the arbiter module 108 may be configured to route data between the media drive 104 in the packet-switched network 202 independently of the CPU 106 . Accordingly, the power consumption module 208 may cause the CPU 106 (and other devices under control of the CPU 106 ) to go to “sleep” such that a state of software being executed on the CPU 106 is retained (e.g., stored in memory) yet the CPU 106 (and corresponding memory) consumes significantly less power when compared with an active state, e.g., configured to execute instructions. In this way, the arbiter module 108 (through use of the power consumption module 208 ) may continue to route data between the media drive 104 in the packet-switched network 202 while the CPU 106 is asleep.

In an implementation, the arbiter module 108 is configured to consume at least an order of magnitude less power than the CPU 106 . In an example, the CPU 106 when in an active state consumes approximately 20 watts (W) of power as opposed to the arbiter module 108 that consumes approximately 0.5 watts of power. Thus, power is conserved by the computer 102 of FIG. 1 by placing the CPU 106 in the sleep state. It should be readily apparent, however, that a variety of other examples of power conservation are also contemplated, such as to put additional devices (e.g., a “Northbridge” and/or a “Southbridge” in a sleep state, further discussion of which may be found in relation to FIG. 3 ).

The arbiter module 108 is further illustrated as including a security module 210 . The security module 210 is representative of functionality of the arbiter module 108 to protect the CPU 106 from virus attacks. For example, the security module 210 is illustrated in FIG. 2 as including an operating system 212 . The operating system 212 may employ software that is configured to scan data managed by the arbiter module 108 for viruses, e.g., to scan data transferred from the packet-switched network 202 to the CPU 106 , from the media drive 104 to the CPU 106 , from the packet-switched network 202 to the media drive 104 , and so on.

Thus, the arbiter module 108 (and more particularly the security module 210 ) may identify viruses before being communicated to the CPU 106 , the media drive 104 , and so on. When a virus is identified, the security module 210 may take a variety of different actions, such as to terminate communication of data from the packet-switched network 202 , delete a compromised file from the media drive 104 , and so on. Thus, the arbiter module may create a “demilitarized zone” (DMZ) between itself and the CPU 106 . Although the arbiter module 108 is described in FIG. 2 as having a power consumption module 208 and a security module 210 that are representative of functionality that may be employed by the arbiter module 108 , it should be readily apparent that a wide variety of other functionality may also be provided by the arbiter module 108 as a result of independent operation from the CPU 106 .

FIG. 3 depicts a system 300 in an example implementation in which the arbiter module 108 of FIGS. 1 and 2 is shown as being implemented with the CPU 106 on a motherboard 302 . The arbiter module 108 may be implemented in a variety of ways, such as a “system on a chip” (SOC), a chipset, and so on. The arbiter module 108 is illustrated as including a processor 304 and a plurality of interfaces (which may be implemented via one or more modules), examples of which are illustrated as a CPU interface 306 , a network interface 308 and a media drive interface 310 .

The network interface 308 is representative of functionality of the arbiter module 108 to connect to the network 110 . For example, the network interface 308 may be configured to connect to a network connection device that is configured to send and receive data via a network 110 . In another example, the network interface 308 may be configured to include the functionality of the network connection device itself. A variety of other examples are also contemplated.

Likewise, the media drive interface 310 is representative of functionality of the arbiter module 108 to connect to the media drive 104 . Thus, the media drive interface 310 may be configured to include functionality to connect directly with the media drive 104 , indirectly through one or more other devices (e.g., via a Universal Serial Bus), and so on.

The CPU interface 306 is illustrated as being communicatively coupled to the CPU 106 via a memory controller 312 (which is also known as a “Northbridge”) and an input-output (I/O) controller hub 314 (which is also known as a “Southbridge”). As illustrated in FIG. 3 , the CPU interface 306 is communicatively coupled to the I/O controller hub 314 , which is communicatively coupled to the memory controller hub 312 , which is communicatively coupled to the CPU 106 .

Memory controller hub 312 is illustrated as being communicatively coupled to a memory interface 316 . The memory interface 316 may be configured to communicatively couple the CPU 106 through the memory controller hub 312 to memory, which may store data to be processed by the CPU 106 . Additionally, the memory controller hub 312 may provide a variety of other functionality, such as to communicatively couple a “high speed” graphics card to the CPU 106 . Thus, the memory controller hub 312 is typically utilized for “fast” capabilities of the computer 102 of FIG. 1 .

The I/O controller hub 314 is illustrated as being communicatively coupled to a general-purpose I/O interface 318 . The I/O controller hub 314 may be utilized to implement “slower” capabilities of the computer 102 of FIG. 1 . For example, the general-purpose input-output interface 318 may be utilized to connect devices to the CPU 106 via a PCI bus; provide a communicative coupling to a BIOS, a serial port, a parallel port, one or more peripheral devices; input/output devices (e.g., keyboard, mouse); and so on. Thus, in this example the motherboard 302 follows a “Northbridge/Southbridge” CPU architecture.

The arbiter module 108 is illustrated in FIG. 3 as being implemented by a processor 304 , with the power consumption module 208 and the security module 210 representing software (e.g., executable modules) that are executable on the processor 304 . The arbiter module 108 , as previously described, represents functionality to manage routing of data between the media drive 104 , the network 110 and the CPU 106 .

Traditionally, routing between the network 110 and the media drive 104 was performed by the CPU 106 in combination with the I/O controller hub 314 . Consequently, the CPU 106 and the I/O controller hub 314 (and the memory controller hub 312 that communicatively couples the I/O controller hub 314 to the CPU 106 ) were active to perform this communication.

However, by providing this functionality by the arbiter module 108 independent of one or more other devices of the computer 102 (e.g., the CPU 106 , the memory controller hub 312 and the I/O controller hub 314 ,) these other devices may be placed in the sleep state to conserve power. Additionally, the security module 210 may provide virus scanning and other security techniques that may be used to protect the computer 102 of FIG. 1 from attack by malicious parties. Further discussion of these techniques may be found in relation to the example procedures.

Generally, any of the functions described herein can be implemented using software, firmware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms “module” and “functionality” as used herein generally represent software, firmware, hardware or a combination thereof. In the case of a software implementation, the module, functionality, or logic represents program code that performs specified tasks when executed on one or more CPUs, e.g., processors. The program code can be stored in one or more computer readable memory devices. The arbiter module features described herein are platform-independent, meaning that the techniques may be implemented on a variety of commercial computing platforms having a variety of processors.

Example Procedure

FIG. 4 depicts a procedure 400 in an example implementation in which routing of data between a network and a media drive is managed by an arbiter module. The following discussion may be implemented utilizing the previously described systems and devices, as well as other systems and devices subsequently described. Aspects of each of the procedures may be implemented in hardware, firmware, or software, or a combination thereof. The procedures are shown as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks.

Routing of data between a CPU, a media drive and a network is managed by an arbiter module (block 402 ). The arbiter module 108 , for instance, may be positioned on a motherboard 302 with the CPU 106 and be responsible for routing of data between the CPU 106 , the media drive 104 , and the network 110 , one to another.

Data is detected that is to be streamed between a media drive in a network without being routed through the CPU (block 404 ). The arbiter module 108 , for example, may detect that a particular stream of the data is to be communicated between the media drive 104 and the network 110 . For instance, the stream may be involved in an upload of data from the media drive 104 through the arbiter module 108 to the network 110 . In another instance the stream may be involved in a download of the data via the network 102 to be stored on the media drive 104 . In each of these instances, however, a determination is made that the CPU is not to be involved in streaming (block 406 ).

Accordingly, an indication may be provided to the CPU that indicates that the CPU is permitted to sleep (block 408 ). For instance, the arbiter module 108 may provide a command to the CPU 106 , which indicates that the CPU 106 (and other devices communicatively coupled to the CPU 106 ) is permitted to sleep. Therefore, the CPU 106 may make a determination of whether to enter a sleep state based on whether other data is to be processed by the CPU 106 , such as by another application, the application that requested the upload and/or download, and so on.

Accordingly, data may be routed between the media drive and the network while the CPU is asleep (block 410 ). When interaction with one or more input devices that are communicatively coupled to the CPU is detected, the CPU may be caused to wake from the sleep (block 412 ). In this way, power may be conserved by the arbiter module 108 as previously described in relation to FIG. 2 yet the CPU 106 is still available to perform desired functions.

One or more security techniques may also be utilized by an arbiter module with data that is to be transferred between two or more of the CPU, the media drive or the network (block 414 ). For example, the arbiter module 108 may utilize a security module 210 to perform a virus scan of data that is to be transferred between the CPU 106 , the media drive 104 and/or the network 110 . Thus, in this example the virus may be prevented from communication “past” the arbiter module 108 to other devices. In another example, the arbiter module 108 may execute a dedicated operation system 212 that is different from an operating system 320 executed on the central processing unit 106 . Thus, the operating system 212 executed on the arbiter module 108 does not share vulnerabilities that may be present on the operating system executed on the central processing unit 106 . A variety of other examples are also contemplated. These techniques may also be applied to a wide variety of other devices, examples of which may be found in relation to the following figures.

FIGS. 5-12 illustrate some examples of various devices that can each be implemented as any form of a device to implement various embodiments of the previously described arbitration techniques. For example, any of the various devices can be implemented as a device that is used to employ arbitration, e.g., a media drive, a computer, and so on. All or a part of these techniques may be employed within signal processing and/or control functionality of the devices, examples of which are as follows.

FIG. 5 illustrates an example media drive that may be embodied as a hard disk drive (HDD) 500 , which includes signal processing and/or control circuit(s) generally identified at 502 . The HDD 500 can also include a magnetic storage media 504 and/or a memory 506 , such as random access memory (RAM), a low-latency nonvolatile memory such as flash memory, read only memory (ROM), and/or other suitable electronic data storage. In various implementations, the signal processing and/or control circuit(s) 502 can be implemented to process data (e.g., any of encoding, decoding, encryption, and/or decryption), perform data calculations, and/or format data. The data can be output to and/or received from at least the magnetic storage media 504 and/or the memory 506 . In addition, the HDD 500 can communicate with a host device (not shown) such as a computer or mobile computing devices, such as a personal digital assistant, cellular phone, media or MP3 player, and/or other devices via one or more wired or wireless communication links 508 . Data communicated by the device may leverage the previously described arbitration techniques as represented by the signal processing and/or control 502 .

FIG. 6 illustrates an example media drive that may be embodied as a digital versatile disc (DVD) drive 600 , which includes signal processing and/or control circuit(s) generally identified at 602 . The DVD drive 600 can also include an optical storage media 604 , mass data storage 606 , and/or a memory 608 , such as random access memory (RAM), a low-latency nonvolatile memory such as flash memory, read only memory (ROM), and/or other suitable electronic data storage. The mass data storage 606 can store data in a nonvolatile manner, and may include a hard disk drive (HDD) such as described with reference to FIG. 5 , which may be a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8 inches.

In various implementations, the signal processing and/or control circuit(s) 602 can be implemented to process data (e.g., any of encoding, decoding, encryption, and/or decryption), perform data calculations, format data, and/or any other signal processing functions associated with a DVD drive. The data can be written to and/or read from at least the optical storage media 604 and/or the memory 608 . In addition, the DVD drive 600 can communicate with an output device (not shown) such as a computer, television, and/or other devices via one or more wired or wireless communication links 610 . Data communicated by the device may leverage the previously described arbitration techniques as represented by the signal processing and/or control 602 .

FIG. 7 illustrates an example computer that may be embodied as a high definition television (HDTV) 700 , which includes signal processing and/or control circuit(s) generally identified at 702 . The HDTV 700 can also include mass data storage 704 and/or a memory 706 , such as random access memory (RAM), a low-latency nonvolatile memory such as flash memory, read only memory (ROM), and/or other suitable electronic data storage. The mass data storage 704 can store data in a nonvolatile manner, and may include an optical storage media as described with reference to FIG. 6 , and/or a drive as described with reference to FIG. 5 , which may be a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8 inches.

In various implementations, the signal processing and/or control circuit(s) 702 can be implemented to process data (e.g., any of encoding, decoding, encryption, and/or decryption), perform data calculations, format data, and/or any other signal processing functions associated with an HDTV. The data can be output to and/or received from at least the memory 706 . In addition, the HDTV 700 includes a wireless local area network (WLAN) interface 708 via which input signals can be received in either a wired or wireless format. HDTV output signals can be generated for a display 710 . Data communicated by the device, whether internally or externally, may leverage the previously described arbitration techniques as represented by the signal processing and/or control 702 .

FIG. 8 illustrates an example computer that may be embodied as a part of a vehicle 800 , which includes a powertrain control system 802 and, optionally, additional vehicle control system(s) 804 . The powertrain control system 802 can receive data inputs from one or more sensors 806 such as temperature sensors, pressure sensors, rotational sensors, airflow sensors, and/or any other suitable sensors. The powertrain control system 802 can receive the data inputs and generate one or more output control signals 808 , such as engine operating parameters, transmission operating parameters, braking parameters, and/or other control signals.

Additional control system(s) 804 may likewise receive data signals from one or more input sensors 810 and/or generate output control signals 812 to one or more output devices. In various implementations, a control system 804 may be part of an anti-lock braking system (ABS), a navigation system, a telematics system, a vehicle telematics system, a lane departure system, an adaptive cruise control system, and/or a vehicle entertainment system such as a stereo, DVD, compact disc, and the like.

The vehicle 800 can also include mass data storage 814 and/or a memory 816 , such as random access memory (RAM), a low-latency nonvolatile memory such as flash memory, read only memory (ROM), and/or other suitable electronic data storage. The mass data storage 814 can store data in a nonvolatile manner, and may include an optical storage media as described with reference to FIG. 6 , and/or a drive as described with reference to FIG. 5 , which may be a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8 inches. In addition, vehicle 800 includes a wireless local area network (WLAN) interface 818 via which input signals can be received in either a wired or wireless format. The powertrain control system 802 also may support connections with a WLAN via the WLAN interface 818 . Data communicated by the device, whether internally or externally, may leverage the previously described arbitration techniques as represented by the powertrain control system 802 and/or the vehicle control system 804 .

FIG. 9 illustrates an example computer that may be embodied as a television set-top box 900 , which includes signal processing and/or control circuit(s) generally identified at 902 . The set-top box 900 can also include mass data storage 904 and/or a memory 906 , such as random access memory (RAM), a low-latency nonvolatile memory such as flash memory, read only memory (ROM), and/or other suitable electronic data storage. The mass data storage 904 can store data in a nonvolatile manner, and may include an optical storage media as described with reference to FIG. 6 , and/or a drive as described with reference to FIG. 5 , which may be a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8 inches.

The set top box 900 can receive data signals from a source 908 , such as a broadband source, and can then output standard and/or high definition audio/video signals suitable for a display 910 , such as a television, monitor, and/or other video and/or audio output devices. In various implementations, the signal processing and/or control circuit(s) 902 can be implemented to process data (e.g., any of encoding, decoding, encryption, and/or decryption), perform data calculations, format data, and/or any other signal processing functions associated with a television set-top box. The data can be output to and/or received from at least the memory 906 and/or the source 908 . In addition, the set-top box 900 includes a wireless local area network (WLAN) interface 912 via which input signals can be received in either a wired or wireless format. The set-top box 900 may also support connections with a WLAN via the WLAN interface 912 . Data communicated by the device, whether internally or externally, may leverage the previously described arbitration techniques as represented by the signal processing and/or control 902 .

FIG. 10 illustrates an example computer that may be embodied as a cellular phone 1000 , which includes a cellular antenna 1002 and signal processing and/or control circuit(s) generally identified at 1004 . The cellular phone 1000 can also include mass data storage 1006 and/or a memory 1008 , such as random access memory (RAM), a low-latency nonvolatile memory such as flash memory, read only memory (ROM), and/or other suitable electronic data storage. The mass data storage 1006 can store data in a nonvolatile manner, and may include an optical storage media as described with reference to FIG. 6 , and/or a drive as described with reference to FIG. 5 , which may be a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8 inches.

In various implementations, the signal processing and/or control circuit(s) 1004 can be implemented to process data (e.g., any of encoding, decoding, encryption, and/or decryption), perform data calculations, format data, and/or any other signal processing functions associated with a cellular phone. The data can be output to and/or received from at least the memory 1008 . In addition, the cellular phone 1000 includes a wireless local area network (WLAN) interface 1010 via which input signals can be received in a wireless format. The cellular phone 1000 may also support connections with a WLAN via the WLAN interface 1010 . In some implementations, the cellular phone 1000 can include a microphone 1012 , an audio output 1014 such as a speaker and/or audio output jack, a display 1016 , and/or an input device 1018 such as a keypad, pointing device, voice actuation, and/or other input device. Data communicated by the device, whether internally or externally, may leverage the previously described arbitration techniques as represented by the signal processing and/or control 1004 .

FIG. 11 illustrates an example computer that may be embodied as a media player 1100 , which includes signal processing and/or control circuit(s) generally identified at 1102 . The media player 1100 can also include mass data storage 1104 and/or a memory 1106 , such as random access memory (RAM), a low-latency nonvolatile memory such as flash memory, read only memory (ROM), and/or other suitable electronic data storage. The mass data storage 1104 can store data, such as compressed audio and/or video content, in a nonvolatile manner. In some implementations, compressed audio files include files that are compliant with an MP3 format or other suitable compressed audio and/or video formats. The mass data storage 1104 may include an optical storage media as described with reference to FIG. 6 , and/or a drive as described with reference to FIG. 5 , which may be a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8 inches.

In various implementations, the signal processing and/or control circuit(s) 1102 can be implemented to process data (e.g., any of encoding, decoding, encryption, and/or decryption), perform data calculations, format data, and/or any other signal processing functions associated with a media player. The data can be output to and/or received from at least the memory 1106 . In addition, the media player 1100 includes a wireless local area network (WLAN) interface 1108 via which input signals can be received in either a wired or wireless format. The media player 1100 may also support connections with a WLAN via the WLAN interface 1108 . In some implementations, the media player 1100 can include an audio output 1110 such as a speaker and/or audio output jack, a display 1112 , and/or an input device 1114 such as a keypad, touchpad, pointing device, voice actuation, and/or other input device. In various implementations, media player 1100 may employ a graphical user interface (GUI) that typically includes menus, drop down menus, icons, and/or a point-and-click interface via display 1112 and/or user input 1114 . Data communicated by the device, whether internally or externally, may leverage the previously described arbitration techniques as represented by the signal processing and/or control 1102 .

FIG. 12 illustrates an example computer that may be embodied as a Voice over Internet Protocol (VoIP) phone 1200 , which includes an antenna 1202 and/or is implemented in connection with a VoIP box that enables a conventional telephone to be plugged in and utilized with VoIP technology. The VoIP phone 1200 also includes signal processing and/or control circuit(s) generally identified at 1204 . The VoIP phone 1200 can also include mass data storage 1206 and/or a memory 1208 , such as random access memory (RAM), a low-latency nonvolatile memory such as flash memory, read only memory (ROM), and/or other suitable electronic data storage. The mass data storage 1206 can store data in a nonvolatile manner, and may include an optical storage media as described with reference to FIG. 6 , and/or a drive as described with reference to FIG. 5 , which may be a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8 inches.

In various implementations, the signal processing and/or control circuit(s) 1204 can be implemented to process data (e.g., any of encoding, decoding, encryption, and/or decryption), perform data calculations, format data, and/or any other signal processing functions associated with a VoIP phone. The data can be output to and/or received from at least the memory 1208 . In addition, the VoIP phone 1200 includes a Wireless Fidelity (Wi-Fi) communication module 1210 via which communication links with a VoIP network can be established. In some implementations, the VoIP phone 1200 can include a microphone 1212 , an audio output 1214 such as a speaker and/or audio output jack, a display 1216 , and/or an input device 1218 such as a keypad, pointing device, voice actuation, and/or other input device. Data communicated by the device, whether internally or externally, may leverage the previously described arbitration techniques as represented by the signal processing and/or control 1204 .

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.