Computing device and method for wireless remote boot in a networked environment

In some embodiments, a secure authenticated remote boot of computing device over a wireless network is performed in a pre-boot execution environment (PXE) using active management technology (AMT) for remote discovery. In these embodiments, a management engine (ME) may maintain full control of a wireless interface and a wireless connection as booting begins. The ME may relinquish control of the wireless interface after a PXE timeout, in response to a shutdown command, or once the device has booted. The ME controls the use of an operating system received from a remote location.

TECHNICAL FIELD

Some embodiments pertain to wireless devices. Some embodiments pertain to remote boots of computing devices.

BACKGROUND

An operating system may use a variety of sources to boot up in various environments. Networked systems allow a computing device to receive start up information from a network server. A Basic Input/Output System (BIOS) defines a firmware interface which is the first code run by a computing device when powered on. The BIOS loads the operating system, identifies, tests and initializes system devices. The BIOS prepares the computing device to operate in a known state so that software may be loaded, executed and given control of the device.

The state of a computing device is defined by a system image and is used by the BIOS. A computer system boots up by executing BIOS instructions that cause an operating system loader program to be loaded from a disk drive into system memory. The BIOS may then cause the computer system to execute the loader program that, in turn, causes the computer system to load portions of the operating system into the system memory. Subsequently, the operating system may execute one or more program(s) to initialize and start execution of the operating system.

Many computing devices are wireless devices that include a wireless adapter card for communicating within a wireless network. Wireless adapter cards may not have sufficient memory storage to store operating code and driver codes used to support wireless networked functionality. Thus what is needed are computing devices and methods that provide for wireless remote boot in a networked environment.

DETAILED DESCRIPTION

The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Examples merely typify possible variations. Individual components and functions are optional unless explicitly required, and the sequence of operations may vary. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims.

The following details some embodiments of a method and apparatus for a wireless remote boot, such as an Operating System (OS) streaming method, in a networked environment having access to a wireless network. In example embodiments, the method and apparatus utilize existing software and firmware instructions (e.g., code), as well as apparatus to retrieve information that may be used to enable networked boot up from a wireless network for a remote computing device. Such techniques may be implemented without additional memory to the wireless cards that implement the wireless connectivity for the computing device, such as wireless-fidelity (Wi-Fi) cards. Existing wireless cards may not have sufficient memory to store operating instructions (e.g., code) and driver codes to support wireless networked functionality.

Some embodiments leverage the central management functions of a central server to provide resources that allow wireless boot up of the computing device. By leveraging wireless network support built into a networked system, it is possible to allow a remote boot up from a wireless server without rebuilding the BIOS and other information used at boot up.

In some embodiments, a secure authenticated remote boot of computing device over a wireless network is performed in a pre-boot execution environment (PXE) using active management technology (AMT) for remote discovery. In these embodiments, a management engine (ME) may maintain full control of a wireless interface and a wireless connection as booting begins. The ME may relinquish control of the wireless interface after a PXE timeout, in response to a shutdown command, or once the device has booted. The ME controls the use of an operating system received from a remote location. These embodiments are described in more detail below. In some embodiments, a host embedded controller interface (HECI) application programming interface (API) is used to communicate with the ME for communicating over the wireless connection, the HECI API to serve as a proxy for the wireless interface when managed by the ME. In some embodiments, a universal network driver interface (UNDI) is used as a host embedded controller interface (HECI) wrapper, the PXE to use the UNDI to communicate with the ME for communicating network traffic over the wireless connection. In some embodiments, the computing device is a wireless communication device configured to communicate in accordance with an IEEE 802.11 standard. In some embodiments, the computing device is a wireless communication device configured to communicate in accordance with an IEEE 802.16 standard. In some embodiments, the computing device is a wireless communication device configured to communicate in accordance with a 3GPP standard for long-term evolution (LTE).

FIG. 1illustrates a computer system100, in accordance with example embodiments. The computer system100includes access to a wireless network122, which may reside within computer system100or may be external. The computer system100also includes a local area network (LAN)120. A central server126may be an enterprise server, a central server for implementing control, updates, and other maintenance of one or more of computing devices124. The computer system100is configured to implement a remote network boot up for the computing devices124using resources of the central server126. Some embodiments implement a PXE, which allows a remote computing device124, such as a workstation, to boot from a server on a network prior to booting the operating system on the local hard drive of the computing device124. The PXE specifies a process to load software onto the remote computing device124from the central server126. Implementation of the PXE involves support components in a BIOS and NIC of the computing device124. The PXE operates to boot the computing device124from the central server126by transferring the boot image file from the central server126. The PXE works with the LAN120and works with multiple OSs.

FIG. 2illustrates a computer system300having an Active Management Technology (AMT) management mechanism for remote discovery, healing and protection of computer systems in accordance with some embodiments. In one embodiment, computer system300employs a silicon-resident AMT. The AMT provides the basis for software designs to address manageability issues, improve the efficiency of remote management and asset inventory functionality in third-party management software, safeguard functionality of agents from operating-system (OS) failure, power loss, and intentional or inadvertent client removal. The AMT allows the computer system300to remotely discover computing assets in multiple operational states. The computer system300stores hardware asset information, such as in FLASH memory, which may be read out even when the computer system300is powered off or has an inoperable OS. The AMT may also provide a general-purpose, non-volatile data store that accepts local or network-based storage commands to work with management or enterprise applications.

Furthermore, the AMT may remotely heal computing assets so as to provide a proactive alert notification of a system problem, even in situations where the computer system300is powered off. The AMT provides Out-Of-Band (00B) access to remotely diagnose, control, and repair the computer system300after software, OS, or hardware failures. The AMT infrastructure may support the creation of setup and configuration interfaces for management applications, as well as network, security, and storage administration.

The hardware architecture of computer system300may be resident in firmware, and may include a processing unit, such a processing unit302, a graphics and memory controller hub308, an I/O controller hub314and a Local Area Network (LAN) controller324. The processing unit302includes software agents304and code for an OS306. The graphics and memory controller hub308includes a micro-controller310, which stores and controls Management Engine (ME)311including firmware to implement various services on behalf of management applications. The computer system300further includes a FLASH memory312, which stores the system BIOS for computer system300. The system BIOS includes machine-readable code used by the ME, and a third-party data store (3PDS) that enables applications to store information as needed in non-volatile memory.

The I/O controller hub314includes filters316, sensors318and Medium Access Control (MAC) layer controller320, which are used to interface with I/O ports and control communications with the computer system300. A LAN controller324is communicatively coupled to the I/O controller hub314, and includes OOB unit326and wired network interface328. Network interface328may be an Ethernet interface although this is not a requirement. A WLAN controller325is communicatively coupled to the I/O controller hub314, and includes OOB unit330and wireless network interface332. The computer system300includes multiple Double Data Rate (DDR) memory units, such as DDR2322, to transfer data on rising and falling edges of a clock signal. Each DDR2322is communicatively coupled to the graphics and memory controller hub308.

The AMT functionality further enables management applications to access client computers in a variety of states by accessing the radio in a wireless Network Interface Card (NIC). The NIC allows the computer system300to access a wireless network, such as wireless network122(FIG. 1).

FIG. 3illustrates a portion of the computer system300, including the ME311, which in some embodiments, runs on auxiliary power and is available at multiple system power states. The ME311communicates with ME peripherals440, LAN, Direct Memory Access (DMA) and MAC controller430, and wireless interfaces420. Physical layer interface450may be coupled with DMA and MAC controller430. The ME peripherals may include a cryptographic engine, Non-Volatile Memory (NVM), and interfaces to various busses, such as a System-Management Bus (SMBus) or a Serial Peripheral Interface Bus (SPI) bus. As illustrated, the ME peripherals440communicates with FLASH memory312via a Serial Peripheral Interface (SPI) communication bus. The SPI communication bus allows multiple masters to share a single FLASH device, including use of the information stored in the FLASH memory312, including the BIOS code, firmware, 3PDS, and so forth.

A specified amount of main memory460may be dedicated to execute ME code and store ME run-time data, such as in a manner similar to a Unified Memory Architecture (UMA), which allows a graphics processing unit to share a memory system, or other computer memory architecture enabling shared memory. In some embodiments, the ME311stores ME code in a compressed form in FLASH memory312, and therefore may be accessed without accessing a hard drive (not shown). In such embodiments, the computer system300prevents access of the ME memory range by the processing unit302(FIG. 2), thus adding security to avoid the ability of malicious software to access the ME code.

The ME311can access its dedicated memory space even when the computer system300is in a powered down state. The graphics and memory controller hub308(FIG. 2) may dynamically switch among various memory power states to allow ME access to FLASH memory312. This capability allows for low average power since the memory is ‘on’ only when it is to be used.

As illustrated, ME311may also include various firmware and/or software for performing AMT applications402, administration (ADMIN) services404, core services406, management services408, and network services410. ME311may also include management engine hardware abstraction layer412and threadX kernel414.

FIG. 4illustrates an Active Management Technology (AMT) core hardware architecture resident in a computing device in accordance with example embodiments. Communication between the host OS500and the ME311may be accomplished by a Host Embedded Controller Interface (HECI). The HECI defines a bi-directional communication protocol where either the host OS500or the network server530may initiate transactions. In one embodiment, the network server530implements AMT firmware to initiate transactions. In some embodiments, transactions may be completed asynchronously by the firmware, such as AMT firmware, and then synchronized later.

The ME311may employ an external memory, such a memory storage device or system having a UMA type memory architecture. The external UMA memory523includes a main memory dedicated to execute ME code for ME311and to store ME run-time data for ME311. The use of the external UMA memory523may be similar to UMA memories employed in graphics applications. In some examples, the external UMA memory523may include or be located adjacent to a graphics UMA memory space. In this way, the external UMA memory523may include an ME memory space and a graphics memory space. From the perspective of the host OS500, the graphics memory space may appear slightly larger than the ME memory space.

The host OS500may include AMT firmware defined by an AMT server application502, an AMT client application504, and a routing application506. A protocol engine508controls communications and AMT processing, while a TCP/IP unit510controls Transmission Control Protocol (TCP) and Internet Protocol (IP) handling of communications. TCP operates at a high level and provides ordered delivery of data packets and information from source to destination. IP is used to package datagrams or packets from source to destination for communication in a packet-switched network. The suite of protocols for Internet use is referred to as TCP/IP. The protocol engine508may be designed to handle multiple protocols, such as Simple Object Access Protocol (SOAP), HyperText Transfer Protocol (HTTP) and Transparent LAN service (TLS). The SOAP protocol is a specification for exchanging structured information to implement web services. SOAP may rely on application layer protocols for process-to-process communications, such as Remote Procedure Call (RPC) or HTTP, for message negotiation and transmission. TLS is a service linking networks, such as remote Ethernet networks. TLS allows the connected networks to be viewed as one contiguous network from the user perspective.

Additionally, the host OS500includes a host HECI driver514as well as a LAN driver512and LAN hardware516. The host HECI driver514provides an interface for the HECI interface or HECI bus that allows the host OS500to communicate directly with the ME311. The bi-directional, variable data rate bus enables communication of system management information and events. The bus may be implemented with four wires, a request and grant pair along with a serial transmit and receive data pair. The LAN driver512and LAN hardware516provide an interface for the host OS500and the ME311.

FIG. 4further illustrates the ME311as including an AMT application518, a protocol engine520, a host HECI driver522, and a LAN driver524. The host HECI driver522operates in a complementary manner to the host HECI driver514, communicating over the HECI interface bus. The LAN driver524communicates with the LAN hardware516through a serial link such as an M-link.

The host OS500further communicates with the network server530via a connection between LAN hardware516and LAN hardware438. The network server530also includes an AMT server application432, a protocol engine434, and a LAN driver436. The protocol engines520and434are similar to the protocol engine508, and may provide complementary functions.

Message flow between a first client pair may continue without regard to the message flow between a separate client pair. Messages may be of various lengths, and may be subject to the limitations of the user's receive buffer (rather than limitations of the HECI drivers). The HECI drivers514and522may comprise software or firmware drivers, which break messages into packets to support lengthy messages. Flow control is communicated by HECI bus messages, and the HECI driver may wait to transmit a message until an associated client has a receive buffer ready to accept the data.

A FLASH memory, such as FLASH memory312(FIG. 3), associated with AMT is shared by multiple masters (Host, ME, and LAN). The FLASH memory312is a non-volatile memory, wherein FLASH refers to the ability to electrically erase and program large blocks of the memory array at the same time. The FLASH memory312maintains information stored without requiring power. The FLASH protection scheme does not allow any master to perform a direct write to FLASH, and read/write permissions to each FLASH region are enforced in hardware. Each master has a grant Override register that can override its descriptor permissions, giving other masters access to the region they own. A security-override strap is used during initial manufacturing and service returns to program (or re-program) the FLASH memory312.

FIG. 5illustrates an example of a Network Interface Controller (NIC)600, which may be used in a system employing an AMT architecture. The NIC600implements an interface that is OS-independent. The NIC600includes an event manager602, an asset manager604, a store manager606and an administration unit608. The NIC600further includes a protocol engine610, which implements a SOAP-based application programming interface (API) consistent with a Web Services Description Language (WSDL). The NIC600also includes an HTTP unit612and a TCP/IP unit614. In some embodiments, each service supported by the NIC600is provided by a distinct WSDL file. Security measures for the network interface may include the use of HTTP Digest, such as defined in Request For Comments (RFC) 2617, entitled “HTTP Authentication: Basic and Digest Access Authentication,” by J. Franks et al, dated June 1999, promulgated by the Internet Engineering Task Force, and authentication by username/password credentials. The NIC600also supports TLS-secured connections and mutual authentication. The NIC600includes an AMT certificate616and an administration unit608. As illustrated inFIG. 5, the NIC600interfaces with the central server126including a web browser application620and a management application622.

FIG. 6is a block diagram illustrating a network configuration700including a central server720and a computing device701having access to a wireless network. The computing device701further includes a processor703controlling operation of the computing device701, including to run code, such as firmware or software, resident in the ME708and resident or received into the BIOS710. As illustrated, the computing device701has a firmware portion having a BIOS710, a PXE memory, such as PXE Option Read Only Memory (OPROM)702, a network interface705. The PXE OPROM702provides code to enable PXE for the computing device. The network interface705interacts with the ME708of Memory Controller Hub (MCH)706.

The network interface in one example is an HECI API. The HECI API provides a software interface that is used to communicate to MCH706including an ME708so as to access AMT capabilities. Communication between the local host operating system (OS) and the ME708is accomplished by means of a HECI driver. The HECI function operates bi-directionally, as either the host OS or AMT firmware can initiate transactions.

The computing device701operationally may boot up from the central server720or a wireless network. The ME708implements AMT functionality for the computing device.

According to an example embodiment, when an option is set to enable PXE and the wireless interface is set by the remote IT console to enable AMT, the ME708continues to have full control of the WLAN interface and connection even when the computing device701starts booting. The ME708may relinquish control of the WLAN interface after a PXE timeout or on receipt of HECI commands to de-initialize or shut down. The commands may be received from BIOS710or PXE OPROM702. The BIOS710or PXE OPROM702may directly use the network interface705, such as a HECI API, to communicate with the ME708to send and receive the network traffic over the WLAN (not shown inFIG. 6). The network interface705will serve as a proxy or virtual interface for the WLAN interface that is managed by the ME708. The ME708will have full control of the WLAN interface and authentication exchange until the time the system boots.

In an example embodiment, the network interface is consistent with the HECI protocol, having commands given in Table I in accordance with some example embodiments. The HECI protocol includes call made to the ME to initiate AMT actions.

TABLE IHECI ProtocolHECI CALLDEFINITIONHECISignals the ME to initialize the WLAN interface,INITIALIZEbased on Wi-Fi profile that is pre-provisioned andtake control of the WLAN interface/connection.HECISignals the ME to relinquish control of the WLANDEINITIALIZEconnection; this is where the wireless LAN connectionis transitioned back to the host.HECI OPENSignals the ME to open the WLAN interface.HECI CLOSESignals the ME to close the WLAN interface.HECI TXSignals the ME to transmit a packet over the WLANinterface.HECI RXSignals the ME to call a receive packet handler when apacket is received over the WLAN interface (interruptdriven).HECI POLLThis call polls the ME to find out if a packet has beenreceived over the WLAN interface.

FIG. 7is a block diagram illustrating a network configuration800including a central server820and a computing device801having access to a wireless network. In one example, the computing device801includes a BIOS810, a PXE OPROM802, a UNDI (Universal Network Driver Interface)803and a network interface804. The UNDI803is defined in a PXE specification, and acts as the HECI wrapper. The BIOS810and the PXE OPROM802use the UNDI803to communicate with the ME808in order to send and receive network traffic over the WLAN (not shown). The network interface805interacts with the ME808of MCH806. The UNDI803internally uses the network interface804, such as defined in Table Ito talk with the ME808. The UNDI803supports the AMT functionality while providing flexibility and ease of integration with a variety of technologies for implementing the PXE OPROM802. Table II defines the actions in operation of UNDI803in accordance with some example embodiments.

TABLE IIUNDI ProtocolUNDI ACTIONDESCRIPTIONUNDI STARTUPThis is the UNDI API responsible for initializing the contents of theUNDI code and data segment for proper operation. Information fromthe PXE structure and the first PXENV_START_UNDI API call is usedto complete this initialization. The rest of the UNDI APIs will not beavailable until this call has been completed.UNDI CLEANUPThe call prepares the network adapter driver to be unloaded frommemory. This call is made just before unloading a universal NICDriver. The rest of the API is not available after this call executes.UNDI INITIALIZEThis call resets the adapter (i.e., the NIC) and programs it with defaultparameters. The default parameters are those supplied in response tothe most recent UNDI_STARTUP call. The application callsPXENV_UNDI_OPEN to logically connect the network adapter to thenetwork. This call is made by an application to establish an interface tothe network adapter driver. Note: When the PXE code makes this callto initialize the network adapter, it passes a NULL pointer for theProtocol field in the parameter structureUNDI RESETThis call resets and reinitializes the network adapter with the same setADAPTERof parameters supplied to Initialize Routine. Unlike Initialize, this callopens the adapter; that is, it connects logically to the network. Thisroutine cannot be used to replace Initialize or Shutdown calls.UNDIThis call resets the network adapter and leaves it in a safe state forSHUTDOWNanother driver to program it. Note: The contents of thePXENV_UNDI_STARTUP parameter structure need to be saved bythe universal NIC Driver in case PXENV_UNDI_INITIALIZE is calledagain.UNDI OPENThis call activates the adapter's network connection and sets theadapter ready to accept packets for transmitting and receiving.UNDI CLOSEThis call disconnects the network adapter from the network. Packetscannot be transmitted orreceived until the network adapter is open againUNDI TRANSMITThis call transmits a buffer to the network. The media header for thePACKETpacket can be filled by the calling protocol, but it might not be. Thenetwork adapter driver will fill it if required by the values in theparameter block. The packet is buffered for transmission providedthere is an available buffer, and the function returnsPXENV_EXIT_SUCCESS. If no buffer is available the function returnsPXENV_EXIT_FAILURE with a status code ofPXE_UNDI_STATUS_OUT OF_RESOURCE. The number of buffersis implementation-dependent. An interrupt is generated on completionof the transmission of one or more packets. A call toPXENV_UNDI_TRANSMIT is permitted in the context of a transmitcomplete interruptUNDI ISRThis API function will be called at different levels of processing theinterrupt. The FuncFlag field in the parameter block indicates theoperation to be performed for the call. This field is filled with the statusof that operation on return.

FIG. 8illustrates a state diagram900including a method for operating a computing device having connection to a central server and to a wireless network. As illustrated, the computing device powers on and enters the null state904. On occurrence of various events transitions the computing device either to an active state910where the device downloads software and a system image to boot the computing device or to a passive state902where the device downloads software and a system image to boot the computing device.

From the null state904on an uplink event for the central server on a networked connection, considered an uplink event, the computing device transitions to the active state910. An uplink event, for example, may be the detection of a connection to a network, such as an Ethernet network. In this way, when the computing device initially connects to the network, a connection is detected as an uplink event. Further while in the null state904, on an uplink event for the wireless network, the computing device transitions to the passive state902. The uplink event may be when the computing device detects the wireless network, or when the wireless capability of the computing device is turned on. Other uplink events may be implemented according to the computing environment and system configurations.

From the active state910, on a link down event, the computing device transitions back to the null state904. Further, when authentication to the central server fails, such as when the central server implements an AMT mechanism and transitions to the passive state902, the computing device may also transition back to the null state904.

From the passive state902, on a link down event the computing device transitions to the null state904. When the computing device fails to authenticate on the wireless network host, the computing device then transitions to the active state910.

FIG. 9is a flowchart illustrating a method1000for managing booting up of an operating system in a computing device. The computing device powers on1002and enters a null mode1003, which corresponds to a pre-boot mode of an operating system for the computing device. At decision point1004determines if the computing device has a network connection, such as an Ethernet connection. For a network connection, on an uplink event1020, the computing device attempts to authenticate and connect on a central server. When the computing device authenticates1022on the Network connection the computing device enters an active mode1024, else the computing device remains in null mode1003. In the active mode1024, the computing device loads software onto the computing device from the central server. The computing device receives the system image1026from the central server, and uses this information to boot up1014the computing device.

Returning to decision point1004, when a network connection is not available, the computing device receives an uplink event to the wireless network, which is referred to as a host server. At decision point1008, when the computing device authenticates on the wireless network, an uplink event is processed1006and the computing device enters a passive mode1010in which the device will boot from the wireless network. The computing device receives1012system image information from the wireless network, and uses this information to boot1014the computing device. If the computing device fails to authenticate at decision point1008, the computing device remains in the null mode1003.

Both embodiments involve the ME708(FIG. 6) and 808(FIG. 8) relinquishing control of a NIC after the computing device has booted. The triggers used by ME708,808to relinquish control to the host OS after boot include a configurable timeout for the HECI processing or UNDI API triggers (e.g., calls to DEINITIALIZE or SHUTDOWN). When the platform of the computing device is connected to both a LAN, such as LAN120shown inFIG. 1, and a WLAN, such as the wireless network122also shown inFIG. 1, one of the networks will be used for PXE boot. In some embodiments, connection to the LAN and the WLAN is mutually exclusive at this point. Processing may be based on the Set8021XPXEEnable interface used with a wired or a wireless interface.

In an example embodiment, the PXE information stored in the computing device, such as PXE OPROM702and802is used to support AMT and remote connections to the wireless network. In one example, API activities are performed to configure PXE support with AMT implementing a wireless network. In one example, the computing device issues a call to Set8021XPXEEnable_WLAN. The PXE timeout period is set to a default value of 120 seconds. The API sets the PXE_WLAN_Config_flag in the AMT firmware. The computing device then issues a call to Get8021XPXEEnable_WLAN

The host booting procedures transitions according to and may be implemented using the following code:

If (PXE_WLAN_Config_flag && !(PXE_boot_complete)){AMT continues in active mode until the remote boot is completed.}
PXE boot completes on detection of any of the PXE features of Table III, i.e., HECI trigger, 802.1x/EAP packets, or PXE timeout. In response the computing device sets PXE_boot_complete flag in the AMT firmware.

In some embodiments, a machine-readable medium is comprised of instructions, which when implemented by one or more machines, cause the one or more machines to receive a registration request from a service provider, store a set of information for the service provider in a memory storage unit, and transmit an indication of the service provider to at least one service consumer in the wireless communication network.

Unless specifically stated otherwise, terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, may refer to an action and/or process of one or more processing or computer systems or similar devices that may manipulate and transform data represented as physical (e.g., electronic) quantities within a processing system's registers and memory into other data similarly represented as physical quantities within the processing system's registers or memories, or other such information storage, transmission or display devices. Furthermore, as used herein, a computing device includes one or more processing elements coupled with computer-readable memory that may be volatile or non-volatile memory or a combination thereof.

Embodiments may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by at least one processor to perform the operations described herein. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). A machine-readable medium may include, but is not limited to, FLASH memory, optical disks, Compact Disks-Read Only Memory (CD-ROM), Digital Versatile/Video Disks (DVD), Read Only Memory (ROM), Random Access Memory (RAM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), magnetic or optical cards, propagation media or other type of machine-readable media suitable for storing electronic instructions. For example, embodiments may be downloaded as a computer program, which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).

Having disclosed embodiments and the best mode, modifications and variations may be made to the disclosed embodiments while remaining within the scope of the embodiments as defined by the following claims.