Storage device control responsive to operational characteristics of a system

[0001] 1. Field of the Invention

[0002] The present invention relates to storage device control and, more particularly, to such control based on system operation information.

[0003] 2. Description of the Related Art

[0004] Information processing systems such as computer systems typically include storage devices such as hard drives or other computer readable media. The efficiency and speed of hard drives, for example, often play a significant role in the overall performance of the system. While it is advantageous to the information processing speed of the system for a hard drive to operate at a peak state (e.g., rotating at a maximum speed), such a peak state often wastes energy and increases unnecessary noise. While turning off a hard drive eliminates energy waste and noise generation, the significant ramp times from a sleep state to a maximum speed for reading the hard drive can cause a significant increase in the overall data access time, waste energy for low priority or short drive accesses and cause unnecessary heat and noise generation.

[0005] In a typical system, when the performance of processing devices is increased, the storage devices operate at a maximum speed. Actual storage access events can be used to determine if a storage device should be on or off/asleep, but such implementations cannot predict what the system storage access requirements are likely to be, since they have no knowledge of the performance of system processing devices or other system operational characteristics. Accordingly, a means of predicting storage access requirements and a flexible means of advantageously controlling storage devices in view thereof is desirable.

[0006] It has been discovered that system operational characteristics (e.g., power level, clock frequency, processor utilization, operating system time slice utilization, size and age of queued jobs) may be used to predict storage access requirements for the system. By predicting the storage access requirements of a system, a storage subsystem may be advantageously controlled to anticipate actual storage accesses. Historical information processing platform (IPP) operational characteristics may be used in place of or in addition to the use of a contemporaneous, non-IPP characteristic such as the existence of an immediately pending storage access request.

[0007] For example, software can be used to predict storage access requirements based on an average IPP performance state over a period of time. A storage device or array of such devices can be configured to operate, for example, at selected speeds no greater than that required to process the predicted storage access requirements. The storage access prediction may be based, for example, on the frequency and voltage at which the CPU of an IPP is running or based on other system performance indicators such as job backlog and age and size thereof. Various controllable characteristics such as the speed of a hard drive's storage media, the current applied to a read/write head, etc., can be increased or decreased continuously or to discrete values in response to the moving average indicators which provide advance warning of potential processing, and therefore potential storage access, swings. In this example, sudden toggling of a hard drive between a maximum access speed and a sleep state can be avoided using the software and method described herein.

[0008] A method of operating a storage device coupled to an information processing system is provided. In one embodiment, the method includes the step of controlling a controllable characteristic of the storage device in a manner dependent at least in part on an operational characteristic of the information processing system. In another embodiment, the method includes the step of monitoring an operational characteristic of the information processing system, and the step of predicting a device access requirement dependent at least in part upon the operational characteristic of the information processing system.

[0009] In another embodiment, an information processing system includes a processing platform, a storage platform, and a storage controller. The storage controller is coupled to receive information regarding an operational characteristic of the processing platform after execution of the storage controller is initiated. The storage platform is coupled to the processing platform and is coupled to receive control information from the storage controller after execution of the storage controller is initiated.

[0010] In another embodiment, an apparatus includes at least one computer readable medium with encoded information on the at least one computer readable medium. The apparatus includes encoded information for monitoring an operational characteristic of a system, and encoded information for generating storage control information dependent upon the operational characteristic of the system.

[0011] Of course, the foregoing is a summary and thus may contain, often by necessity, simplifications, generalizations and omissions of detail. Consequently, those skilled in the art will appreciate that the foregoing summary is illustrative only and that it is not intended to be in any way limiting of the invention. Other aspects, inventive features, and advantages of the present invention, which is defined solely by the claims, may become apparent from the description set forth below.

[0016] The above referenced figures and the following discussion are intended to provide details of at least one example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention which is properly defined in the claims following this description.

[0017] FIG. 1 shows an information processing system 100 including components for monitoring system performance characteristics and controlling storage elements responsive thereto. System 100 is any type of information processing system such as a computer system (e.g., portable, workstation or other type of computer system). System 100 includes an information processing platform such as processor 110, and an information storage platform such as hard drive 160. Processor 110 is coupled to hard drive 160 via bus 150. System 100 may include many other elements in various other configurations which are not shown so to avoid obfuscation of the invention.

[0018] Processor 110 includes operating system 130, file system 130 and storage control daemon 140. Operating system 120 is coupled to file system 130, which in turn is coupled to storage control daemon 140. Operating system 120, file system 130 and storage control daemon 140 operate within the context of processor 110, either within the hardware of processor 110 as shown, or within hardware coupled to processor 110 within an overall information processing platform of system 100. Storage control daemon 140 may be provided as an integral part of operating system 120 or as a separate software or firmware module.

[0019] Processor 110 is capable of operation at more than one frequency and at more than one power level. The frequency and power level may be tuned “on the fly” during operation of processor 110, typically using a temporary halt of processor 110, followed by a switch in frequency and/or power level, followed by a resumption of processing. This capability is useful for addressing efficiency and power savings considerations.

[0020] Storage control daemon 140 is a program that runs continuously and in the background of other running programs or processes. In other embodiments, storage control daemon 140 includes computer processes which may or may not execute continuously or in the background of other programs or processes executing on processor 110.

[0021] Storage control daemon 140 monitors the operation of all or portions of system 100 (e.g., processor 110), makes storage access predictions based on such observations, and forwards control information to other programs or processes as appropriate based on such predictions. Storage control daemon 140 provides such control information to hard drive 160 to affect control of certain controllable characteristics of hard drive 160.

[0022] For example, storage control daemon 140 monitors the power level of processor 110 in order to predict storage access requirements of hard drive 160. In one such embodiment, processor 110 is coupled to provide a digital voltage identification signal to a digital-to-analog converter (DAC) via a digital control bus (not shown). The digital signal is determined at least in part by system/processor performance information. For example, if processor 110 is being underutilized (e.g., with a number of unused processor cycles), the DAC provides a corresponding analog control signal to a power supply (not shown) of the system. The power supply is coupled to provide a controlled power supply signal to processor 110 and various other components of system 100 to control the level of power received such components to save power or otherwise maximize efficiency. The level of power supplied to processor 110 may be used as a predictive indicator of storage access requirements by storage control daemon 140.

[0023] Alternatively, or in addition, processor 110 may also include or be coupled to a module (hardware or otherwise) which controls the frequency of processor 110 to maximize efficiency, speed and/or power conservation. In some cases, frequency is reduced to save power when processor 110 is not being fully utilized. Frequency is increased to maximize information processing speed when a great number of instructions must be executed. In such cases, storage control daemon 140 may use the frequency level to predict storage access requirements of hard drive 160.

[0024] File system 130 includes and/or provides information regarding utilization of processor 110 which may be used by storage control daemon 140 to determine the likelihood of storage access requests. The presence, absence or number of active or pending storage access requests may also be monitored to make predictions to generate control information to control certain characteristics of hard drive 160. For example, file system 130 may include a list of pending file transfer jobs, job lengths/sizes, age of each job, etc. This information may be received by storage control daemon 140 and used to predict the extent of future storage access requirements. For example, the sum, for all tasks, of each task waiting time for a pending input/output (I/O) transfer multiplied by the size of the corresponding pending I/O transfer.

[0025] Hard drive 160 includes storage 180 for storing information for use within system 100. Storage 180 commonly, but not necessarily, includes a rotatable storage medium and a read/write or I/O head for accessing (e.g., reading and/or writing) the rotatable storage medium of storage 180. Hard drive 160 also includes hard drive controller 170 for controlling the access of storage 180. Hard drive controller 170 is coupled to storage 180 and to file system 130. In alternative embodiments, storage 180 may be coupled directly to file system 130 or other elements of processor 110.

[0026] Hard drive controller 170 may be envisioned as a microcontroller or a software or firmware module operating on a microcontroller, depending on the context. Hard drive controller 170 controls storage access requests from the information processing platform (e.g., processor 110) of system 100 to facilitate the transfer of information to and from storage 180 and processor 110 and, potentially, various processing elements associated with processor 110.

[0027] Hard drive controller 170 also controls certain physical aspects of the hard drive 160 responsive to communications from storage control daemon 140. Control of certain characteristics of the hard drive may be useful to minimize noise, heat and waste while still balancing such conditions against performance requirements of the hard drive. Also, as shown herein, hard drive 160 may be controlled by storage control daemon 140 and hard drive controller 170 using predictions based on operational characteristics of elements of system 100 such as the current and past usage of processor 110, frequency and power of processor 110, and storage access job queue status. This allows enhanced efficiency of operation due to the predictive component of such control.

[0028] Hard drive controller 170 includes various subcontrollers for controlling various controllable characteristics of controller 170. Some exemplary controllable characteristics are the rotational speed of the storage medium, the seek/settle speed of the I/O head, and the local frequency of the clocks of a local microcontroller on hard drive 160. Hard drive controller 170 includes rotation controller 172 to control the rotational speed of storage 180. Hard drive controller 170 includes seek controller 174 to control the seek speed of the I/O head. Hard drive controller 170 includes local frequency controller 176 to control the frequency of the local microprocessor clocks of hard drive controller 170.

[0029] Storage 180 may also include a storage control module (not shown) in the form of a software module stored for execution by processor 110 in order to initiate operation of storage control daemon 140. The storage control module may be a stand alone module or a submodule of a power control module or some other software module. The storage control module initiates operation of a storage control daemon “in” processor 110. The operation of system 100 under the influence of the storage control module and storage control daemon 140 is described herein and with reference to FIGS. 2–3.

[0030] FIG. 2 shows an operational flow of various modules operating within the context of system 100. Generally, these modules (e.g., storage control daemon 140) operate to determine controllable characteristics (e.g., speed, frequency, power, queue status) of devices (e.g., an information storage platform such as a hard drive) coupled to an information processing platform. For example, the storage control daemon 140 operate to determine the whether the speed, frequency and power characteristics of an information storage platform such as hard drive 160 are controllable. The status of certain system operational characteristics of system 100 such as processor frequency, processor power, OS time slice usage and job queue status may then be monitored. These operational characteristics are monitored in view of certain user-programmable requirements. Device access requirements (e.g., for the information storage platform) are predicted, and the controllable characteristics of the devices are controlled based on the predictions.

[0031] For example, at determine controllable characteristics step 210, a control module determines whether devices coupled to an information processing platform have any controllable characteristics, and if so, what those characteristics are. Within the context of exemplary system 100, storage control daemon 140 can query hard drive 160 to request it to enumerate its performance states so that storage control daemon can determine which characteristics of hard drive 160 are controllable and what form control information should take when it is sent to hard drive 160 to control those characteristics.

[0032] For example, storage control daemon 140 may determine whether a rotational storage element of storage 180 is controllable to variable rotational speeds, what maximum, intermediate and minimum speeds may be applicable, and whether storage 180 is fast or sluggish by retrieving indications of change times between speeds. Storage control daemon 140 may also determine whether hard drive 160 includes a read/write head which has a controllable seek speed (e.g., to aid in conservation of current). Storage control daemon 140 may also determine whether local hard drive controller 170 of hard drive 160 includes a variable frequency or power level. Other elements of hard drive 160 may be controllable, for example, to allow greater power savings and/or efficiency of operation of hard drive 160. Other elements that may be fine tunable include certain detector characteristics, such as detector thresholds and detector timing characteristics for detecting information stored on storage 180, along with characteristics of filters and amplifiers and other elements of the read/write circuitry of hard drive 160.

[0033] After determining controllable characteristics during step 210, storage control daemon 140 checks a user specification during step 220 to determine if the user of system 100 has programmed specific performance requirements and/or power saving requirements for devices within system 100. For example, the user of system 100 may use a graphical user interface coupled to processor 110 to program certain power-saving requirements for system 100, such as sleep modes during periods of non-use or decreased use in which decreased access speeds or other reduced access requirements are likely. The user may specify when the system will be deemed in a high use mode with high performance requirements and when the system will be deemed in a power savings mode with overriding power saving requirements.

[0034] After check user specification step 220, storage control daemon 140 monitors the operation of system 100. As described above, certain operational characteristics of processor 110 may be monitored, such as the frequency of processor 110 and/or the power level of processor 110, and such as the job queue status.

[0035] Another type of operational characteristic which may be monitored during system operation monitoring step 230 is the utilization of processor 110. The operating system and applications executing in system 100 may be monitored during step 230 by storage control daemon 140 to determine the extent of utilization of the processing capability of processor 110 by such applications. For example, operating system (OS) 120 of processor 110 assigns time slices to various applications executing on processor 110, and operating system 120 keeps performance statistics based on the time slices. Storage control daemon 140 samples information regarding the extent to which each application utilizes its time slice, for example, by periodically querying the OS scheduler for such utilization information. For example, if many applications are not utilizing their full time slice, then processor 110 is being under-utilized. If processor 110 is being underutilized, then the performance of processor 110 may be ratcheted down, with a corresponding effect on future storage access requirements. Thus, such utilization information is useful in making storage device control decisions.

[0036] One way of measuring processor utilization is to sample the currently pending process list provided by file system 130. The processor run time used by each process since the last sampling may be calculated along with the actual elapsed time since the last sampling. The ratio of used process time to elapsed time yields one type of utilization metric.

[0037] Another type of operational characteristic is processor performance and/or performance history. The performance of processor 110 may be monitored by storage control daemon 140 during step 230. Performance can be measured using various processor characteristics. For example, the power supply voltage level is an indication of the performance of processor 110. Another indicator of processor performance is the frequency of processor 110. The voltage level and frequency may be varied together or independently at different times for power conservation purposes and for performance purposes. For example, during times where high performance is necessary, the frequency and power level may be increased, and during times where high performance is not necessary, the power level and frequency may be decreased to conserve power. Processor performance history may be monitored by continually or periodically measuring the performance of processor 110 and maintaining, for example, a running average of performance measurements (e.g., the last three measurements) to describe the recent history of the processor's power level and frequency.

[0038] The performance of processor 110 is typically closely related to storage access requirements. For example, when the frequency and/or power level of processor 110 are low, storage access requirements are likely to be low as well. Similarly, if processor 110 is being underutilized by applications, storage access requirements are likely to be low. Consequently, the current performance state and/or the recent performance history of processor 110, and patterns thereof, are relevant to efficient control of devices such as hard drive 160 and to making predictions regarding the anticipated storage access requirements for such devices.

[0039] After storage control daemon 140 begins monitoring the operational characteristics of system 100 during monitoring step 230, storage control daemon 140 predicts device access requirements during step 240. A predictive algorithm may be applied to the utilization and/or performance information during prediction step 240. For example, storage control daemon 140 may predict that device access requirements for hard drive 160 are decreasing as a result of decreased processor frequency and/or power level, which in turn typically results from decreased information processing requirements. Alternatively, storage control daemon 140 may predict that device access requirements for hard drive 160 are increasing as a result of increased processor frequency and/or power level, which in turn typically results from increased information processing requirements, which often lead to increased information storage access requirements.

[0040] Usage models can be generated to make predictions of processor operation based on the history of the operation of the processor. Thus, the history of the processor can be used to predict the future performance of the processor, and accordingly, to predict the future storage access requirements of the system and thereby prevent certain heat conditions from ever occurring. Predictive storage control and power conservation are particularly useful in mobile systems.

[0041] By analyzing the utilization and performance information in view of the predictive algorithm during prediction step 240, storage control information may be generated during control step 250. Storage control daemon 140 then controls certain device characteristics during device control step 250 based on the predictions made during prediction step 240. For example, if the job queue has few jobs and the jobs are small, or if the frequency of processor 110 is decreased, storage control daemon 140 observes the decrease during monitoring step 230 and then makes a prediction that hard drive access requirements will also decrease for hard drive 160 during prediction step 240. Control information is then generated to allow storage control daemon 140 or another application to take one or more actions depending on the operational observations made during monitoring step 230. These steps may be continually repeated for the duration of the operation of system 100.

[0042] Storage control daemon 140 can directly control the performance states of hard drive 160, for example, by selecting rotation speeds from a set of speeds previously provided by hard drive 160 during step 210. Storage control daemon 140 can also somewhat indirectly control hard drive 160 by sending control information such as percentage based operation parameters which can be interpreted by hard drive controller 170 to select specific rotation speeds.

[0043] Storage control daemon 140 can use rotational controller 172 to decrease the rotation of the rotational storage element 180, use seek controller 170 to decrease seek speeds of the read/write head of storage element 180, and even use local frequency controller 176 to reduce the operating frequency of hard drive controller 170, all in response to the predicted reduction in device access requirements. After control step 250, the system is again (or simultaneously) monitored during monitoring step 250.

[0044] FIG. 3 shows an example of operation of storage 180 under the control of storage control daemon 140. At time 305, the rotational storage element 180 is rotating at a speed of 3600 revolutions per minute (RPMs). This may be during a period of high speed information processing where a maximum speed of the rotational storage element is required. From time 305 to time 310, storage control daemon is monitoring the status of certain operational characteristics of system 100, and making predictions regarding storage access requirements.

[0045] By time 310, storage control daemon 140 has predicted reduced device access requirements for hard drive 160. Accordingly, storage control daemon 140 directs rotation controller 172 of hard drive controller 170 to in turn direct storage 180 to reduce the rotational speed from the maximum 3600 RPMs to an intermediate speed of 600 RPMs at time 315 as shown by the solid line. In contrast, another system might detect an absence of pending jobs at a time later than time 310, and induce the hard drive into a sleep state, as shown by the dotted line.

[0046] The speeds shown in FIG. 3 are exemplary; other speeds may be used and even a continuous speed range may be used. Speed may be selected based on power usage and/or noise generation. For example, a relatively inaudible speed may be selected when storage access requirements are anticipated to be low but non-negligible.

[0047] Storage 180 continues to rotate at a speed of 600 RPMs until time 325. During that time, storage control daemon 140 monitors the operation of system 100 (e.g., the operational characteristics of processor 110). There may be processor usage up-ticks during the time from time 315 to 325, but those temporary up-ticks may or may not be sufficient to trigger a higher storage access prediction which would trigger a higher speed. In another system, the up-ticks might induce the hard drive to increase to the maximum speed (not shown) for even small and low priority storage access requests.

[0048] At time 325, storage control daemon 140 has predicted increased device access requirements (e.g., due to increased frequency or processor usage). Accordingly, rotation controller 172 instructs storage 180 to increase its operational speed to a second intermediate speed of 1800 RPMs. Storage 180 achieves a rotational speed of 1800 RPMs at time 330. In another system, the storage might not increase its speed until an actual storage access is made at time 333, thereby inducing a maximum speed at time 340. Meanwhile, storage 180 is already ready to process storage accesses at time 335, and even at time 330, before time 340.

[0049] Storage 180 continues to operate at the intermediate speed of 1800 RPMs from time 330 to time 360. During this time, hardware control daemon 140 again monitors operational characteristics of system 100 and makes predictions. At time 360, hard drive controller 170 uses rotation controller 172 to decrease the operational speed of storage 180 in response to a predicted decrease in device access requirements. Accordingly, storage 180 reduces speed from 1800 RPMs to 600 RPMs from time 360 to time 370. Storage 180 then operates at 600 RPMs from time 370 to time 375.

[0050] At time 375, storage control daemon 140 has predicted further reduced device access requirements, and accordingly, directs storage 180 to essentially shut down by reducing rotational speed to 0 RPMs. This may be as a result of a sleep state of processor 110 during which no information needs to be processed and, therefore, no information from storage 180 needs to be accessed. This may also be a result of certain observed system characteristics meeting certain user defined requirements.

[0051] As shown, the foregoing operation of system 100 (shown with a solid line) is in contrast to control of other devices (shown with a dotted line) which may operate in one of two states: an operational, maximum speed state and a sleep, zero-speed state. Such a system may perceive a cessation in device access requests after time 310, and switch to a sleep state to await further device access requests. If such a request comes at time 325, then such a system would power the device to the maximum speed to process the request after time 325. The delay due to a lack of prediction of access requirements, coupled with the delay in powering up from such a low (here, zero) speed to a maximum operational value will delay the time at which processing of the request begins from a potential time of 330 when the device arrives at an intermediate speed using the process of FIG. 2 to a time of 340 after the device would arrives at a maximum speed. Although the access request may be processed more quickly at the maximum speed, the access request may be processed in a very reasonable time at an intermediate speed since the access request was being processed earlier at the intermediate speed. Greater power savings and reduced heat and noise are realized at the intermediate speed.

[0052] The above description is intended to describe at least one embodiment of the invention. The above description is not intended to define the scope of the invention. Rather, the scope of the invention is defined in the claims below. Thus, other embodiments of the invention include other variations, modifications, additions, and/or improvements to the above description.

[0053] In one embodiment, system 100 is a computer system such as a personal computer system, laptop or even a computer server system. Other embodiments may include different types of computer systems. Computer systems are information handling systems which can be designed to give independent computing power to one or more users. Computer systems may be found in many forms including but not limited to mainframes, minicomputers, servers, workstations, personal computers, notepads, personal digital assistants, various wireless devices and embedded systems. A typical computer system includes at least one processing unit, associated memory and a number of input/output (I/O) devices.

[0054] A computer system processes information according to a program and produces resultant output information via I/O devices. A program is a list of instructions such as a particular application program and/or an operating system. A computer program is typically stored internally on computer readable storage medium or transmitted to the computer system via a computer readable transmission medium. A computer process typically includes an executing (running) program or portion of a program, current program values and state information, and the resources used by the operating system to manage the execution of the process. A parent process may spawn other, child processes to help perform the overall functionality of the parent process. Because the parent process specifically spawns the child processes to perform a portion of the overall functionality of the parent process, the functions performed by child processes (and grandchild processes, etc.) may sometimes be described as being performed by the parent process.

[0055] Those skilled in the art will recognize that boundaries between logic blocks are merely illustrative and that alternative embodiments may merge logic blocks or circuit elements or impose an alternate decomposition of functionality upon various logic blocks or circuit elements. Moreover, alternative embodiments may combine multiple instances of a particular component. For example, in the above-described embodiment, multiple processors may be used, and multiple storage devices may be used. Similarly, those skilled in the art will recognize that boundaries between the functionality of the steps and operations shown in FIG. 2 and described above are merely illustrative. The functionality of multiple operations may be combined into a single operation, and/or the functionality of single operations may be distributed in additional operations. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be altered and/or some operations may occur simultaneously in various other embodiments.

[0056] Unless specifically restricted, the operations discussed herein may consist of steps carried out by system users, hardware modules and/or software modules. Thus, the operations referred to herein may correspond to modules or portions of modules (e.g., software, firmware or hardware modules). For example, although the described embodiment includes software modules, the various exemplary modules may be application specific or general purpose hardware modules. The software modules discussed herein may include script, batch or other executable files, or combinations and/or portions of such files. The software modules may include a computer program or subroutines thereof encoded in computer-readable media. The functionality of operations referred to herein may correspond to the functionality of modules or portions of modules in various embodiments.

[0057] Additionally, those skilled in the art will recognize that the boundaries between modules are merely illustrative and alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules. For example, the modules discussed herein may be decomposed into submodules to be executed as multiple computer processes. Moreover, alternative embodiments may combine multiple instances of a particular module or submodule.

[0058] Each of the blocks/operations of FIG. 2 may be executed by a module (e.g., a software module) or a portion of a module or a computer system user. Thus, the above described method, the operations thereof and modules therefor may be executed on a computer system configured to execute the operations of the method and/or may be executed from computer-readable media. The method may be embodied in a machine-readable and/or computer-readable medium for configuring a computer system to execute the method. Thus, the software modules may be stored within and/or transmitted to a computer system memory to configure the computer system to perform the functions of the module.

[0059] The software modules described herein may be received by system 100, for example, from a computer readable media (e.g., storage 180 or another computer readable media). The computer readable media may be permanently, removably or remotely coupled to system 100. The computer readable storage media may include, for example and without limitation, any number of the following: magnetic storage media including disk and tape storage media; optical storage media such as compact disk media (e.g., CD-ROM, CD-R, etc.) and digital video disk storage media; nonvolatile memory storage media including semiconductor-based memory units such as FLASH memory, EEPROM, EPROM, ROM; ferromagnetic digital memories; volatile storage media including registers, buffers or caches, main memory, RAM, etc. The data transmission media including computer networks, point-to-point telecommunication equipment, and carrier wave transmission media, just to name a few. Other new and various types of computer-readable media may be used to store and/or transmit the software modules discussed herein.

[0060] It is to be understood that the architectures depicted herein are merely exemplary, and that in fact many other architectures can be implemented which achieve the same functionality. In an abstract, but still definite sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being “operably connected”, or “operably coupled”, to each other to achieve the desired functionality.

[0061] Because the above detailed description is exemplary, when “one embodiment” is described, it is an exemplary embodiment. Accordingly, the use of the word “one” in this context is not intended to indicate that one and only one embodiment may have a described feature. Rather, many other embodiments may, and often do, have the described feature of the exemplary “one embodiment.” Thus, as used above, when the invention is described in the context of one embodiment, that one embodiment is one of many possible embodiments of the invention.

[0062] Notwithstanding the above caveat regarding the use of the words “one embodiment” in the detailed description, it will be understood by those within the art that if a specific number of an introduced claim element is intended in the below claims, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present or intended. For example, in the claims below, when a claim element is described as having “one” feature, it is intended that the element be limited to one and only one of the feature described. Furthermore, when a claim element is described in the claims below as including or comprising “a” feature, it is not intended that the element be limited to one and only one of the feature described. Rather, for example, the claim including “a” feature reads upon an apparatus or method including one or more of the feature in question. That is, because the apparatus or method in question includes a feature, the claim reads on the apparatus or method regardless of whether the apparatus or method includes another such similar feature. This use of the word “a” as a nonlimiting, introductory article to a feature of a claim is adopted herein by Applicants as being identical to the interpretation adopted by many courts in the past, notwithstanding any anomalous or precedential case law to the contrary that may be found. Similarly, when a claim element is described in the claims below as including or comprising an aforementioned feature (e.g., “the” feature), it is intended that the element not be limited to one and only one of the feature described merely by the incidental use of the definite article.

[0063] Furthermore, the use of introductory phrases such as “at least one” and “one or more” in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an.” The same holds true for the use of definite articles.

[0064] While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, various modifications, alternative constructions, and equivalents may be used without departing from the invention claimed herein. Consequently, the appended claims encompass within their scope all such changes, modifications, etc. as are within the true spirit and scope of the invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. The above description is not intended to present an exhaustive list of embodiments of the invention. Unless expressly stated otherwise, each example presented herein is a nonlimiting or nonexclusive example, whether or not the terms nonlimiting, nonexclusive or similar terms are contemporaneously expressed with each example. Although an attempt has been made to outline some exemplary embodiments and exemplary variations thereto, other embodiments and/or variations are within the scope of the invention as defined in the claims below.