System and method for transparent wireless bridging of communication channel segments

Systems and methods for transparent wireless bridging of communication channels are provided. A plurality of wireless bridge devices are each deployed on a wired communication channel segment and listen for traffic to build a table of MAC addresses for the network devices on each respective segment. The bridges also collectively form a wireless mesh network and publish the MAC addresses on the wireless mesh network so each bridge receives MAC address information for every segment. Accordingly, a sending device on a first segment sends a communication to a target device on a second segment. The respective first bridge passes the communication along through the wireless mesh network to the respective second bridge and the first bridge also sends an acknowledgement to the sending device on behalf of the target device. This proxy acknowledgement allows the wireless bridge system to account for potential latency over the wireless mesh network while at the same time complying with latency requirements and meeting or exceeding the overall round-trip time for network communications.

BACKGROUND

1. Field of the Invention

The present invention is generally related to wired and wireless networking and is more specifically related to transparent bridging of communication channel segments.

2. Related Art

A wireless network is typically an unreliable medium for packet data communication. This is generally true because packet loss rates and latency are higher in wireless networks compared to wired networks with equivalent bandwidth. However, significant cost savings can be achieved by implementing wireless networks rather than wired networks. One such sector where significant savings can be achieved is in the building automation control network (“BACnet”) field, using building automation protocols such as BACnet, Lonworks, ARCnet, RS485, RS232 or any other building automation protocol.

Unfortunately, wireless networks are poor solutions for building automation/BACnet implementations because building automation/BACnet requires reliable packet delivery at low latencies. For example, BACnet master-slave-token-passing (“MSTP”) requires reliable packet delivery. This reliability is divided into a certain amount of time for the device to respond (Tusage_delay) and a certain amount of time to transmit the data (Tusage_delay+Tusage_timeout). In BACnet/MSTP, the network transmission time can be no worse than 5 ms. Therefore, conventional wireless communication networking technologies are unsuited for BACnet applications and what is needed is a system and method that overcomes the significant problems described above.

SUMMARY

Accordingly, systems and methods are presented that allow for transparent wireless bridging of communication channel segments on a network such as BACnet/MSTP or BACnet/IP. The solutions described herein provide for the required reliable packet delivery where necessary and meet the packet latency expectations described by the BACnet protocol.

One embodiment of the invention includes a plurality of wireless bridge devices that are each deployed on a segment (or are directly connected to a particular network device). The bridges listen for traffic on their respective segments and build a table of media access control (“MAC”) addresses of the BACnet/MSTP or BACnet/IP network devices on their respective segment. The bridges also collectively form a wireless point-to-point, peer-to-peer or mesh network. After collecting the MAC address information, the bridges publish the MAC addresses on the wireless network and in turn receive MAC address information about the network devices on other segments. The MAC address propagation can take place on a control channel of the wireless point-to-point, peer-to-peer or mesh network. Each bridge then maintains a table of MAC address and the corresponding IP address of the bridge through which each network device can be reached.

During operation, when a device on a first segment sends a communication to a device on a second segment, the first bridge passes the communication along through the wireless network and also sends an acknowledgment to the sending device on behalf of the target device. This proxy acknowledgment allows the network communications to account for potential latency over the wireless network while at the same time complying with the latency requirements of the underlying communication protocol. The proxy message can be implemented for any communication, including poll for master (“PFM”) communications, confirmed requests and token passing messages.

By implementing the proxy messaging scheme, the wireless bridge allows multiple segments to be transparently linked while maintaining the reliability and latency requirements of the protocol. Other features and advantages of the present invention will become more readily apparent to those of ordinary skill in the art after reviewing the following detailed description and accompanying drawings.

DETAILED DESCRIPTION

Certain embodiments as disclosed herein provide for systems and methods for transparent wireless bridging of network or serial communication segments using any radio platform such as 802.11, 802.15, 802.16, WiFi, ZigBee, ultra wide band (“UWB”), WiMAX, WAN radios, Bluetooth, and the like. For example, one method as disclosed herein allows for a wireless enabled bridge apparatus to monitor traffic on a segment and pass remotely destined packets from a sending network device over a wireless mesh network for delivery to the target network device on a different segment. The bridge additionally sends a proxy acknowledgment message to the sending device in order to maintain compliance with the latency requirements for the native communication protocol.

After reading this description it will become apparent to one skilled in the art how to implement the invention in various alternative embodiments and alternative applications. For example, the systems and methods can be implemented in both wired and wireless networks and bridge both wired segments and wireless segments implemented via direct communication links (e.g., serial connection, Bluetooth connection). However, although various embodiments of the present invention will be described herein, with the primary example being a wireless mesh bridge, it is understood that these embodiments are presented by way of example only, and not limitation. As such, this detailed description of various alternative embodiments should not be construed to limit the scope or breadth of the present invention as set forth in the appended claims.

FIG. 1is a network diagram illustrating an example system for wireless bridging of communication channels according to an embodiment of the present invention. In the illustrated embodiment, the system comprises four bridge devices, namely110,120,130, and140. Each bridge has a data storage area, respectively1,2,3, and4. The bridges are each communicatively coupled with one or more network devices10,12,14,20,22,30,32,34, and40via a network or direct communication channels. For example, bridge110is connected to network devices10,12, and14via a BACnet/MSTP network and bridge130is connected to network devices30,32, and34via another type of network, for example BACnet/IP. Additionally, bridge140is connected to network device40via a direct serial communication link conforming to the RS-485 protocol, and bridge120is connected to network devices20and22via another type of direct communication link, for example Bluetooth.

In the illustrated embodiment, bridge device110, which is representative of the other bridge devices120,130, and140, can be any type of processor driven device capable of communicating with a network device such as network device10over a communication channel and capable of communication with another bridge device over wireless network100. The bridge device110can be configured for wired or wireless communication, or both. It can have a single or multiple radios to enable this communication. The bridge device110is configured to facilitate communications by receiving communications from the communication channel or wireless network100and providing those communications to the target network device on the local communication channel or on a remote communication channel via the wireless network100. The bridge device110may support one or more communication protocols, including but not limited to: BACnet/IP, BACnet/Ethernet, BACnet/ARCnet, BACnet/MSTP, BACnet/PTP, and BACnet/Arcnet, just to name a few. Examples of a general purpose wireless communication device and a general purpose computer device that could be used as a bridge device are described later with respect toFIGS. 12 and 13.

In the illustrated embodiment, network device10, which is representative of the other network devices12,14,20,22,30,32,34, and40can be any type of processor driven device capable of communicating with other network devices and a bridge device over a communication channel. In various embodiments, the network devices can be computer workstations, field controllers, HVAC devices, thermostats, RFID readers, sensors, cameras, laptops, cell phones, personal digital assistants (“PDA”), gaming consoles, or any other network infrastructure devices. The network devices are configured to communicate over a BACnet/MSTP network or any other single-drop or multi-drop serial communication channel. Examples of a general purpose wireless communication device and a general purpose computer device that could be used as a network device are described later with respect toFIGS. 12 and 13.

In the illustrated embodiment, the wireless network100is a wireless mesh network communicatively coupling bridge devices110,120,130, and140. Additional devices may also be part of the wireless network100. In alternative embodiments, the wireless network100can be any sort of 802.X wireless network. Advantageously, a wireless mesh network is very efficient for bridging communications between the various communication channels and can minimize network delays in communications.

In the illustrated embodiment, the various communication channels can be direct links or networks and can include BACnet/MSTP, raw RS-485, BACnet/PTP, raw RS-232, Bluetooth, infrared, and others such as BACnet/IP, BACnet/Ethernet, BACnet/ARCnet, and BACnet/Arcnet. A communication channel can be wired or wireless and serves to communicatively connect the various devices on the communication channel with each other and also with a bridge device.

“Although multiple segments or trunks are shown inFIG. 1it should be understood that the wireless bridge110serves to function as a bridge between multiple segments running like protocols. For example, multiple MSTP segments can be bridged into a single network and multiple IP segments can be bridged into a single network. Importantly, it should also be understood that the wireless bridge110can bridge multiple MSTP segments and multiple IP segments at the same time. Accordingly, the wireless bridge110can be configured as shown whereby individual bridges are connected to segments of various types.”

FIG. 2is a network diagram illustrating an example system for wired bridging of communication channels according to an embodiment of the present invention. In the illustrated embodiment, four bridge devices112,122,132, and142are communicatively coupled over a wired network, namely network102. In alternative embodiments, different network types may be employed for the network102. For example, in one embodiment, the wired network102may be Ethernet. The bridge devices are each in communication with their respective network devices including network automation engine (“NAE”)16, and other network devices24,26,36, and42. The other network devices can be any variety of network devices. The communication channels between the bridge devices and the various network devices can be direct wired physical connections and include BACnet/MSTP, raw RS-485, BACnet/PTP, raw RS-232, and the like. These communication channels can also be direct wireless connections over a wireless physical medium.

FIG. 3is a network diagram illustrating an example system for combined wired and wireless bridging of communication channels according to an embodiment of the present invention. In the illustrated embodiment, bridges114,124,134, and144are communicatively coupled via wireless network104, bridge150, bridge160, and wireless network106. As will be understood by those having skill in the art, alternative network configurations may also be employed to bridge geographically disjoint communication channel segments. For example, bridge114may be in Seattle and bridge144may be in San Diego and wireless network104may include the Internet, a cellular GPRS network or other wide-area network as well as local area networks.

Accordingly, the latency times for network communications even on a dedicated wire segment may be too great for implementation of a single BACnet network across that distance. Advantageously, the present invention can bridge the geographically disjoint segments and connect network device18and network device44as if they were on the same physical wire. This can be achieved through the proxy technique such that the network latency requirements are met via proxy responses from a bridge device, coupled with reliable communications over wireless networks104and106in order to meet the overall round trip time for communication as required by the protocol.

The various networks described inFIGS. 1-3can be any of a variety of network types and topologies and any combination of such types and topologies. For example, the networks can be a wired network, a wireless network or any combination of these. For example, in one or more embodiments, a network can be any of a plurality of networks including private, public, circuit switched, packet switched, personal area networks (“PAN”), local area networks (“LAN”), wide area networks (“WAN”), metropolitan area networks (“MAN”), 802.11, 802.15, 802.16, WiFi networks, WiMAX networks or any combination of these. In one or more embodiments, a network may include the particular combination of networks ubiquitously known as the Internet.

FIG. 4is a block diagram illustrating an example bridge device20according to an embodiment of the present invention. In the illustrated embodiment, the bridge device20is configured with a data storage area5and comprises proxy module200, address table module210, and reliability module220.

The data storage area5can be any sort of internal or external, fixed or removable memory device and may include both persistent and volatile memories. The function of the data storage area5is to maintain data or executable modules for long term storage and also to provide efficient and fast access to instructions for applications or modules that are executed by the bridge device20.

In one embodiment, the proxy module200is configured to send responses to network devices on behalf of other network devices on other communication channel segments. For example, the proxy module200may send a response to a network device that sends a PFM communication. This way, the network device sending the PFM communication receives a response indicating that the target device received the communication (even though the target device may not have yet received the communication). This prevents the sending device from timing out the communication and maintains the integrity of the communications with respect to latency compliance.

The address table module210is configured to manage an address table and update and maintain the entries in the address table. In one embodiment, the address table module210adds entries to the address table when it encounters a new MAC address on its local segment. The address table module210also removes entries from the table if no communications from the particular device with the MAC address have been received for a period of time. Advantageously, this timeout period can be configurable. Advantageously, it can also remove the device under explicitly defined circumstances under which a device that should exist would exhibit a certain behavior; for example, once a token is passed to a device in a BACnet/MSTP network, it should use the token within 500 ms. The address table module210also adds entries to the table when it receives new entries from a bridge device. Advantageously, the address table module210can have a mechanism to synchronize its entries with other bridge devices, so that all bridge devices' address table modules have the same contents. This way, the address table for each bridge includes an entry for the network devices on the local segment as well as the network devices on the remote segments being monitored by other bridge devices.

The reliability module220is configured to maintain reliable communications on the local segment by ensuring that proxy responses are sent prior to any timeout conditions. The reliability module220is configured to spoof network devices by providing certain timely responses to communications, thereby allowing communications to continue under the total round trip latency timeout metrics rather than the total round trip timeouts in combination with acknowledgment timeouts. The reliability module220is advantageously configured to provide proxy responses for any sort of communication that may be sent by a network device that requires a timely interim response in advance of the complete data communications. Examples of these types of communications may include but are not limited to Indications, Requests and token passing communications in a BACnet/MSTP network.

FIG. 5is a block diagram illustrating an example proxy module200according to an embodiment of the present invention. In the illustrated embodiment, the proxy module200comprises a token module250, a PFM module260, and a confirmed request module270. The token module250is configured to manage communications regarding token passing and generate appropriate proxy responses for a remote network device that is the target device for a token passing communication. The PFM module260is configured to manage communications regarding PFM requests and generate appropriate proxy responses for a remote network device that is the master at the time the PFM communication is sent. The confirmed request module270is configured to manage communications regarding BACnet Data Expecting Reply requests, generate the appropriate proxy messages on the sending and receiving end, and forward the responses at an appropriate time.

As will be understood by one having skill in the art, these message types, namely token, PFM, and BACnet data expecting reply, are specific MAC layer messages designed to prevent collisions on a network that uses a token-passing regime (versus collision detection/random backoff as in Ethernet, or timeslots as in time division multiple access, etc). Accordingly, it should also be understood that the same techniques can be applied to implement these aspects of the invention in other embodiments using, for example, BACnet/IP and other protocols.

FIG. 6is a block diagram illustrating an example address table according to an embodiment of the present invention. In the illustrated embodiment, the address table comprises a plurality of entries, with each entry having an internet protocol (“IP”) address and an associated MAC address. Advantageously, the table will also identify the type of entry; e.g. if it is a master or a slave node. The MAC address is the MAC address of a network device on a segment of the communication channel and the associated IP address is the IP address for the bridge device. Advantageously, address tables are shared by the bridges in a system so that each bridge has the MAC address of each network device on the various segments that make up the system and an associated IP address of the bridge device that is the proxy for that network device on the mesh network. This address table is substantially different from conventional address tables where IP addresses and MAC addresses for the same device are paired in each entry.

FIG. 7is a flow diagram illustrating an example process for propagating MAC addresses to a plurality of wireless bridges according to an embodiment of the present invention. This process may be carried out by a series of bridge devices in a system such as that previously described with respect toFIGS. 1-3. Initially, in step280the bridge monitors its segment for data packets that identify the sending network device on the segment. Various packets are examined by the bridge and the various MAC addresses for the network devices on the local segment are added to the address table, as shown in step285. Next, in step290the bridge sends its list of MAC addresses out on the wireless bridge, for example in a control channel. The other bridges in the network do the same.

In step300, the bridge receives an address pair or a MAC address. For example, an address pair is received by the bridge over the network and is sent by a bridge device that couples the local MAC address from its segment with its own IP address. Additionally, the bridge may receive a MAC address from a packet on its local segment. Once received, in step305the bridge determines if the MAC address or the IP address and MAC address pair are in its address table. Advantageously, it determines the type of device based on the class of message received. If the MAC address or address pair is present, then the process loops back to receiving the next address pair or MAC address. If the MAC address or address pair are not in the address table, then in step310the bridge adds the entry to its table. Although not shown, if the bridge adds a new local segment MAC address to its table, then it loops back to step290where the pair of the new local segment MAC address and the IP address for the bridge are propagated out over the network to the other bridge devices in the system.

FIG. 8is a flow diagram illustrating an example process for handling local segment communications according to an embodiment of the present invention. This process may be carried out by a bridge device in a system such as that previously described with respect toFIGS. 1-3. Initially, in step330the bridge receives a communication from a network device on its local segment. The bridge determines in step335if the network device is present in its address table. If it is not, then the MAC address for the network device is added to the table in step340(and the pair is propagated as previously described). If it is in the table then in step345the bridge resets a silence timer for the network device that tracks the presence of the device on the local segment of the bridge. Notably, devices that time out on a local segment are removed from the address table.

Next, in step350the bridge determines whether the received communication is destined for a remote device that is accessible via the wireless bridge. If the communication is not destined outside of the local segment, then in step355the bridge drops the communication as it will be received by the target device via the local segment unless it is necessary to copy the message elsewhere to prevent remote silence timers from expiring. If, as determined in step350the communication is destined for a network device via the wireless bridge, then the bridge processes the communication according to a remote handling procedure. If the communication is destined for an unknown network device, the message is treated as a broadcast and sent to all segments.

FIG. 9is a flow diagram illustrating an example process for handling remote segment communications according to an embodiment of the present invention. This process may be carried out by a bridge device in a system such as that previously described with respect toFIGS. 1-3. Initially, in step370the bridge receives a communication that is destined for a remote network device that is accessible via the wireless bridge. Next, in step375the bridge examines the communication to determine if it is a Poll For Master. If the communication is a Poll For Master, then in step380the bridge timely sends a proxy response to the sending network device and forwards the PFM communication to the target device via the wireless bridge. In one embodiment, any responsive communication to the PFM request from the target device can be filtered by the bridge so that the proxy response is not duplicated. This filtering can be done in all cases where a proxy response is sent by a bridge.

If the communication is not a PFM request, as determined in step375, then in step390the bridge examines the communication to determine if it is a token passing communication. If the communication is a token passing communication, then in step400the bridge waits for a predetermined period of time (defined by Turnaround) and then in step405sends a proxy response to the sending network device. In step410, if the bridge is configured to support one token for the whole network (the “hub” model), it forwards the token to the destination; if the bridge is configured to support one token for each segment attached to a bridge device (the “switch” model), the bridge simulates the behavior of remote devices, including passing along any forwarded communication for each remote device.

If it is not a token passing communication, then the bridge examines the communication to determine if it is BACnet Data Expecting Reply as show in step392. If so, it sends a proxy response in the form of a Reply Postponed message on behalf of the remote device in step393, then forwards the message along to the remote device in step394. In all other cases, the bridge sends the data communication along to the target network device via the wireless bridge, as shown in step395.

FIG. 10is a flow diagram illustrating an example process for handling remote segment communications according to an embodiment of the present invention. This process may be carried out by a bridge device in a system such as that previously described with respect toFIGS. 1-3. In step412, the bridge receives a message from a remote device. In step413, the bridge determines if the message is a Poll For Master or BACnet Data Expecting Reply (“DER”) request. If neither, the bridge forwards the message in step414and does nothing else. If the message is either a PFM or BACnet DER request, in step415a timer is set to the appropriate value (e.g., Tusage_timeout for PFM; Treply_timeout for BACnet DER).

Next, in step416, the bridge forwards the message to the local serial segment. It then waits in step417for a response on the serial bus. If a response is not received on the serial segment before the timer expires, in step418the bridge is finished with handling the expired message and moves on to processing the next message. If a response is received on the serial segment before the timer expires, the bridge forwards the response to the requester in step419.

FIG. 11is a flow diagram illustrating an example process for handling remote segment communications according to an embodiment of the present invention. This process may be carried out by a bridge device in a system such as that previously described with respect toFIGS. 1-3. Initially, in step420the bridge device forwards the communication to the target network device via the wireless bridge. Next, in step425the bridge starts a silence timer on the target device. Advantageously, the silence timer allows the bridge to know when a response from the target device is delinquent according to the communication protocol under which the system is operating, for example, the protocol may be BACnet with its various timeout parameters.

After the silence timer is set, the bridge waits for either a responsive communication from the target device or for the silence timer to expire. If the silence time expires, as determined in step430, then the bridge updates its address table by removing the MAC address and its corresponding IP address for the target device. If, however, the silence timer does not expire then in step440the bridge passes along the responsive communication to its local segment.

FIG. 12is a block diagram illustrating an example wireless communication device450that may be used in connection with various embodiments described herein. For example, the wireless communication device450may be used in conjunction with a bridge device or a network device as previously described with respect toFIGS. 1-3. However, other wireless communication devices and/or architectures may also be used, as will be clear to those skilled in the art.

In the illustrated embodiment, wireless communication device450comprises an antenna system455, a radio system460, a baseband system465, a speaker464, a microphone470, a central processing unit (“CPU”)485, a data storage area490, and a hardware interface495. In the wireless communication device450, radio frequency (“RF”) signals are transmitted and received over the air by the antenna system455under the management of the radio system460.

In one embodiment, the antenna system455may comprise one or more antennae and one or more multiplexors (not shown) that perform a switching function to provide the antenna system455with transmit and receive signal paths. In the receive path, received RF signals can be coupled from a multiplexor to a low noise amplifier (not shown) that amplifies the received RF signal and sends the amplified signal to the radio system460.

In alternative embodiments, the radio system460may comprise one or more radios that are configured to communicate over various frequencies. In one embodiment, the radio system460may combine a demodulator (not shown) and modulator (not shown) in one integrated circuit (“IC”). The demodulator and modulator can also be separate components. In the incoming path, the demodulator strips away the RF carrier signal leaving a baseband receive audio signal, which is sent from the radio system460to the baseband system465.

If the received signal contains audio information, then baseband system465decodes the signal and converts it to an analog signal. Then the signal is amplified and sent to the speaker470. The baseband system465also receives analog audio signals from the microphone480. These analog audio signals are converted to digital signals and encoded by the baseband system465. The baseband system465also codes the digital signals for transmission and generates a baseband transmit audio signal that is routed to the modulator portion of the radio system460. The modulator mixes the baseband transmit audio signal with an RF carrier signal generating an RF transmit signal that is routed to the antenna system and may pass through a power amplifier (not shown). The power amplifier amplifies the RF transmit signal and routes it to the antenna system455where the signal is switched to the antenna port for transmission.

The baseband system465is also communicatively coupled with the central processing unit485. The central processing unit485has access to a data storage area490. The central processing unit485is preferably configured to execute instructions (i.e., computer programs or software) that can be stored in the data storage area490. Computer programs can also be received from the baseband processor465and stored in the data storage area490or executed upon receipt. Such computer programs, when executed, enable the wireless communication device450to perform the various functions of the present invention as previously described. For example, data storage area490may include various modules (not shown) that were previously described with respect toFIGS. 4 and 5.

In this description, the term “computer readable medium” is used to refer to any media used to provide executable instructions (e.g., software and computer programs) to the wireless communication device450for execution by the central processing unit485. Examples of these media include the data storage area490, microphone470(via the baseband system465), antenna system455(also via the baseband system465), and hardware interface495. These computer readable mediums are means for providing executable code, programming instructions, and software to the wireless communication device450. The executable code, programming instructions, and software, when executed by the central processing unit485, preferably cause the central processing unit485to perform the inventive features and functions previously described herein.

The central processing unit485is also preferably configured to receive notifications from the hardware interface495when new devices are detected by the hardware interface. Hardware interface495can be a combination electromechanical detector with controlling software that communicates with the CPU485and interacts with new devices. The hardware interface495may be a firewire port, a USB port, a Bluetooth or infrared wireless unit, or any of a variety of wired or wireless access mechanisms. Examples of hardware that may be linked with the device450include data storage devices, computing devices, headphones, microphones, and the like.

FIG. 13is a block diagram illustrating an example computer system550that may be used in connection with various embodiments described herein. For example, the computer system550may be used in conjunction with a network device or bridge device previously described with respect toFIGS. 1-3. However, other computer systems and/or architectures may be used, as will be clear to those skilled in the art.

The computer system550preferably includes one or more processors, such as processor552. Additional processors may be provided, such as an auxiliary processor to manage input/output, an auxiliary processor to perform floating point mathematical operations, a special-purpose microprocessor having an architecture suitable for fast execution of signal processing algorithms (e.g., digital signal processor), a slave processor subordinate to the main processing system (e.g., back-end processor), an additional microprocessor or controller for dual or multiple processor systems, or a coprocessor. Such auxiliary processors may be discrete processors or may be integrated with the processor552.

The processor552is preferably connected to a communication bus554. The communication bus554may include a data channel for facilitating information transfer between storage and other peripheral components of the computer system550. The communication bus554further may provide a set of signals used for communication with the processor552, including a data bus, address bus, and control bus (not shown). The communication bus554may comprise any standard or non-standard bus architecture such as, for example, bus architectures compliant with industry standard architecture (“ISA”), extended industry standard architecture (“EISA”), Micro Channel Architecture (“MCA”), peripheral component interconnect (“PCI”) local bus, or standards promulgated by the Institute of Electrical and Electronics Engineers (“IEEE”) including IEEE 488 general-purpose interface bus (“GPIB”), IEEE 696/S-100, and the like.

Computer system550preferably includes a main memory556and may also include a secondary memory558. The main memory556provides storage of instructions and data for programs executing on the processor552. The main memory556is typically semiconductor-based memory such as dynamic random access memory (“DRAM”) and/or static random access memory (“SRAM”). Other semiconductor-based memory types include, for example, synchronous dynamic random access memory (“SDRAM”), Rambus dynamic random access memory (“RDRAM”), ferroelectric random access memory (“FRAM”), and the like, including read only memory (“ROM”).

The secondary memory558may optionally include a hard disk drive560and/or a removable storage drive562, for example a floppy disk drive, a magnetic tape drive, a compact disc (“CD”) drive, a digital versatile disc (“DVD”) drive, etc. The removable storage drive562reads from and/or writes to a removable storage medium564in a well-known manner. Removable storage medium564may be, for example, a floppy disk, magnetic tape, CD, DVD, etc.

The removable storage medium564is preferably a computer readable medium having stored thereon computer executable code (i.e., software) and/or data. The computer software or data stored on the removable storage medium564is read into the computer system550as electrical communication signals578.

In alternative embodiments, secondary memory558may include other similar means for allowing computer programs or other data or instructions to be loaded into the computer system550. Such means may include, for example, an external storage medium572and an interface570. Examples of external storage medium572may include an external hard disk drive or an external optical drive, or and external magneto-optical drive.

Other examples of secondary memory558may include semiconductor-based memory such as programmable read-only memory (“PROM”), erasable programmable read-only memory (“EPROM”), electrically erasable read-only memory (“EEPROM”), or flash memory (block oriented memory similar to EEPROM). Also included are any other removable storage units572and interfaces570, which allow software and data to be transferred from the removable storage unit572to the computer system550.

Computer system550may also include a communication interface574. The communication interface574allows software and data to be transferred between computer system550and external devices (e.g. printers), networks, or information sources. For example, computer software or executable code may be transferred to computer system550from a network server via communication interface574. Examples of communication interface574include a modem, a network interface card (“NIC”), a communications port, a PCMCIA slot and card, an infrared interface, and an IEEE 1394 fire-wire, just to name a few.

Communication interface574preferably implements industry promulgated protocol standards, such as Ethernet IEEE 802 standards, Fiber Channel, digital subscriber line (“DSL”), asynchronous digital subscriber line (“ADSL”), frame relay, asynchronous transfer mode (“ATM”), integrated digital services network (“ISDN”), personal communications services (“PCS”), transmission control protocol/Internet protocol (“TCP/IP”), serial line Internet protocol/point to point protocol (“SLIP/PPP”), and so on, but may also implement customized or non-standard interface protocols as well.

Software and data transferred via communication interface574are generally in the form of electrical communication signals578. These signals578are preferably provided to communication interface574via a communication channel576. Communication channel576carries signals578and can be implemented using a variety of wired or wireless communication means including wire or cable, fiber optics, conventional phone line, cellular phone link, wireless data communication link, radio frequency (RF) link, or infrared link, just to name a few.

Computer executable code (i.e., computer programs or software) is stored in the main memory556and/or the secondary memory558. Computer programs can also be received via communication interface574and stored in the main memory556and/or the secondary memory558. Such computer programs, when executed, enable the computer system550to perform the various functions of the present invention as previously described.

In this description, the term “computer readable medium” is used to refer to any media used to provide computer executable code (e.g., software and computer programs) to the computer system550. Examples of these media include main memory556, secondary memory558(including hard disk drive560, removable storage medium564, and external storage medium572), and any peripheral device communicatively coupled with communication interface574(including a network information server or other network device). These computer readable mediums are means for providing executable code, programming instructions, and software to the computer system550.

In an embodiment that is implemented using software, the software may be stored on a computer readable medium and loaded into computer system550by way of removable storage drive562, interface570, or communication interface574. In such an embodiment, the software is loaded into the computer system550in the form of electrical communication signals578. The software, when executed by the processor552, preferably causes the processor552to perform the inventive features and functions previously described herein.