WO2000077585A9

WO2000077585A9 - Peer-to-peer hosting of intelligent field devices

Info

Publication number: WO2000077585A9
Application number: PCT/US2000/015894
Authority: WO
Inventors: Lloyd Adams; Alexander Johnson
Original assignee: Invensys Sys Inc; Lloyd Adams; Alexander Johnson
Priority date: 1999-06-11
Filing date: 2000-06-12
Publication date: 2002-06-20
Also published as: GB2367670A; AU5602800A; WO2000077585A1; GB2367670B; DE10084706T1; GB0129361D0

Abstract

Device configurations are stored in a system including at least two intelligent field devices (IFDs) connected by a communications connection. A configuration for a first IFD is stored in the first IFD, and a backup of the configuration for the first IFD is stored in at least one other IFD. Storing a configuration for the first IFD may include having the first IFD request a configuration from at least one other IFD using the communications connection, an IFD having a stored backup of the configuration for the first IFD transmitting the backup to the first IFD using the communications connection, and the first IFD receiving the transmitted backup and storing the received backup in the first IFD as the configuration for the first IFD. Storing a backup of the configuration for the first IFD may include having the first IFD transmit a backup of the configuration for the first IFD to at least one other IFD using the communications connection, and having the at least one other IFD receive and store the backup of the configuration.

Description

PEER-TO-PEER HOSTING OF INTELLIGENT FIELD DEVICES

BACKGROUND

Intelligent Field Devices (IFDs) are programmable hardware devices that are commonly used in industrial environments. Examples of IFDs include temperature sensors, pressure sensors, and valve positioners. In a typical industrial setting, there may be many independent IFDs, each of which has a configuration that is customized for the requirements of that IFD. A configuration includes instructions regarding the initial settings of the IFD and the manner in which the IFD will respond to anticipated events. Typically, the configuration of a particular IFD differs from configurations of othφ- IFDs. A configuration can be updated as often as necessary to provide optimal IFD and system performance.

In one approach to configuring IFDs, a different configurator is used for each IFD. Typically, a configurator is a vendor-supplied, hand-held device that may be connected directly to an IFD. Often, an IFD must recover its configuration due to a power loss, or after replacement due to device failure. A power loss may be planned, as when an IFD is taken out of service for maintenance, or unplanned, as when a power outage occurs. A common approach to recovery from a loss of power is to store the configuration data in non- volatile memory in the IFD. For large IFDs, it often is not practical to provide a sufficient amount of non-volatile memory within the device itself, due to size, speed, or cost constraints. Therefore, the configuration data for larger IFDs often are stored on a computer and downloaded to the IFD when needed.

When an EFD is replaced due to device failure, its configuration must be restored from outside the IFD. The most commonly used method for restoring configurations to an IFD is through a hand-held configurator. In particular, a hand-held configurator stores the configuration for a particular IFD on a removable medium, such as a memory pack. When that IFD is replaced, the corresponding configurator and memory pack are employed to reload the configuration onto the IFD.

A common alternative method for IFD configuration recovery is the use of a computer as a central configurator that stores all of the configurations. Typically, a portable computer is used for this purpose. To configure an EFD, the computer is connected to the IED and the configuration is downloaded from the computer to the IFD. Often, for the sake of redundancy, a vendor provides both a hand-held configurator and a central configurator system using a portable computer

SUMMARY The invention is directed to stoπng device configurations in a system including at least two interconnected intelligent field devices (IFDs) At least two IFDs and a communications connection between them are provided A configuration for a first IFD is stored m the first IFD, and a backup of the configuration for the first IFD is stored in at least one other IFD The configuration for an IFD includes instructions regarding the initial settings of the IFD and the manner in which the IFD should respond to particular events

Embodiments may include one or more of the following features. For example, stonng a configuration for the first IFD may include having the first IFD request a configuration from at least one other IFD using the communications connection, havmg an IFD with a stored backup of the configuration for the first IFD transmit the backup to the first IFD using the communications connection, and having the first IFD receive the transmitted backup and store the received backup in the first IFD as the configuration for the first IFD Additionally, stonng a backup of the configuration for the first IFD may include having the first IFD transmit a backup of the configuration for the first IFD to at least one other IFD using the communications connection, and having the at least one other IFD receive and store the backup of the configuration

In another implementation, stoπng a backup of the configuration for the first IFD includes having the first IFD transmit a backup of the configuration for the first IFD to at least one other IFD using the communications connection, and having the at least one other IFD receive and store the backup of the configuration. In another implementation, stoπng a configuration for an IFD includes generating the configuration using a configurator program and stonng the generated configuration The configurator program may be stored in an EFD, possibly m the form of a Java applet. The configurator program may be accessed by using a Web browser, which may be stored in a device that is connected to the communications connection, thus enabling the Web browser to access the configurator program through the communications connection.

Alternatively, the Web browser may access the configurator program through a wireless connection between a device on which the Web browser is stored and an IFD Such a wireless connection may be accomplished via an infrared connection, using, for example, a personal digital assistant or a portable computer.

In another implementation, the configurator program may itself be stored on a Web site. A Web browser may be used to access the configurator program, or an Internet gateway component may be used to access the configurator program by translating the Internet- compatible communications into a protocol being used by the IFDs. Likewise, a backup of the configuration for each IFD may be stored on a Web site, and either a Web browser may be used to access the backup configurations for each IFD, or an Internet gateway component may be used to access the backup configurations for each IFD by translating the Intemet- compatible communications into a protocol being used by the IFDs.

Storing the backup of the configuration for the first IFD ma include storing the backup in at least two other IFDs.

Each IFD may include one or more sensors for sensing a process condition or a mechanism for controlling a process condition. The communications connection may include a two-wire connection between the

IFDs. The method may further include providing operating power to at least one IFD through the two-wire connection.

The peer-to-peer hosting method provides several advantages. The first such advantage is the storage of a configurator within an EFD as a Java applet. This feature obviates the need to employ either a hand-held configurator for each IFD or a central configurator (i.e., a portable computer that contains all of the EFD configurations). This prevents confusion that may arise when associating a hand-held configurator with the IFD for which the hand-held configurator is designed. Because Java is platform-independent, it avoids any incompatibility that might otherwise arise between a hand-held configurator and an EFD. The use of a Java applet as a configurator also removes the need for multiple configurator devices. This reduces the cost of both the EFD vendor and the IFD customer because, at most, only one configurator device is needed. This also eliminates work associated with loading the configurator software onto each portable computer used as a central configurator or each hand-held configurator each time that a new EFD configuration is created.

Another advantage results from the use of peer EFDs to provide backup configurations for each other, and the use of an automatic configuration reload program. This is particularly important in the case of device failure and replacement, because the storage of the backup configuration enables the proper configuration to be loaded into the replacement device quickly and automatically. Because there is no need to locate a removable memory pack, problems associated with memory packs, such as swapping or mislabeling, are eliminated The automation provided by this feature also enables a faster and less expensive configuration recovery, because there is no need to perform the manual operation of reloading the configuration with a hand-held device

The Web browser connection feature provides two advantages. The first advantage is the ability to initialize all of the IFDs from a common source, as opposed to initializing each IFD from a separate hand-held configurator. The second advantage is the ability to archive the configurations m a single, easily accessed repository, such as a Web page maintained by a corporate IFD user This allows them to be harvested at once and preserved in a safe location.

Other features and advantages will be apparent from the following descπption, including the drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a block diagram of a system for configunng Intelligent Field Devices (IFDs) using configurators that are resident on the IFDs and a portable computer. Fig. 2 is a block diagram of a system for configunng IFDs using resident Java applet configurators and a hand-held personal digital assistant.

Fig. 3 is a block diagram of a system for configuring IFDs using resident Java applet configurators and an Internet/Intranet gateway connection.

Fig. 4 is a block diagram of a system for configuring EFDs using a web server from either the Internet or an Intranet as a configurator.

Fig. 5 is a block diagram of a system for configuring EFDs using a network-based approach.

Fig. 6 is a block diagram of a system for configunng IFDs using a network-based approach in which the configurator is resident on the network server. Fig. 7 is a block diagram of a system for configuring EFDs using a network-based approach in which an Internet/Intranet gateway provides a conversion to enable compatibility with non-internet industrial protocols. Fig. 8 is a flowchart of a peer-to-peer hosting method for configunng IFDs

DETAILED DESCRIPTION

Referπng to Figs. 1 and 2, a simple network 100 includes two IFDs, IFDl 105 and IFD2 110 It is noted that the system 100 can easily be adapted to include as many IFDs as desired. The network connections for the network 100 can be either direct electncal connections (i.e., wires) or wireless communications links.

The IFDs in the network use a vendor-selected protocol to format data for transmission to each other, as well as to other electronic devices in the network Because of the industnal nature of the environments in which IFDs are typically used, some protocols are not designed for Internet access. Examples of such protocols commonly used in typical industnal environments include HART, FoxComm, PROFIBUS, and Foundation Fieldbus. However, in some cases, IFDs use Internet-compatible protocols such as TCP/IP and UCP/IP. In some implementations, one or more IFDs may support multiple protocols. Typically, each IFD performs a sensing operation, a control operation, or both. IFDs that perform sensing operations, such as temperature sensors, pressure sensors, and flow meters, include one or more sensors for sensing process conditions. In addition to the sensors, these IFJDs include transmitter circuitry for transmitting information about the process conditions to other devices. IFDs that perform control operations, such as valve controllers, include one or more mechanisms for controlling process conditions. These IFDs often receive and use measurement signals provided by sensing IFDs. For example, a valve controller might control the position of a valve in response to a flow rate measurement provided by a flow meter. IFDs may include both sensors and mechanisms for controlling process conditions. EFDs often are interconnected by two-wire connections. A two-wire connection may be used to provide a communications connection between the EFDs. Many IFDs also receive operating power from an associated two-wire connection.

A configurator program for EFDl 105 can be stored within IFDl 105 as a resident configurator software application 115 (e.g., a Java applet), and a resident configurator software application 120 for IFD2 110 can be stored within IFD2 110. These resident configurator applications can be accessed using a processor, such as, for example, a handheld device 122 such as a personal digital assistant (e.g., a Palm III), or a portable computer 123, m communication with the IFD through, for example, a direct electncal connection or an infrared link. The configurator program of an IFD can be used to generate a configuration for the IFD. First, the processor downloads the configurator program from the IFD The processor then runs the configurator program and generates a configuration file in response to inputs to the program from a user Finally, the processor uploads the configuration file to the IFD, which stores the configuration in the memory of the IFD. Thus, a configuration 125 for IFDl 105 is stored in the memory of IFDl 105, and a configuration 130 for IFD2 110 is stored in the memory of IFD2 110.

In some implementations, each IFD can be programmed to store a backup version of its configuration on one or more peer devices. Thus, in the system of Fig. 2, a backup version 140 of the configuration for IFDl 105 is stored on IFD2 l ib, and a backup version 135 of the configuration for IFD2 110 is stored on IFDl 105. Typically, a backup configuration is generated each time an EFD's configuration is modified.

Each IFD also can be programmed to automatically check for the presence of a backup configuration at a peer IFD whenever it has lost power, either due to an outage or due to device failure and replacement. For example, upon power-up, an IFD might be programmed to broadcast a configuration request message identifying the IFD by network address and directed to all peer devices. An IFD having a backup configuration for the broadcasting IFD would respond by sending that backup configuration to the broadcasting IFD. The sending IFD also might include a backup copy of its own configuration for storage on the broadcasting IFD.

Refernng to Fig. 3, a peer-to-peer hosting system 300 uses a network approach to interconnect three exemplary IFDs. Again, it is noted that the system 300 can easily be adapted to include as many EFDs as desired. IFDl 305, EFD2 310, and EFD3 315 are networked together and include associated Java applet configurators 323, 325, 330. A Java applet configurator can be used to configure each IFD, which then stores its own configuration in memory. Hence, IFDl 305 stores its own configuration 335 in memory, IFD2 310 stores its own configuration 340 in memory, and EFD3 315 stores its own configuration 345 in memory. Additionally, each of the three EFDs can store a backup version of another IFD's configuration. For example, EFD1 305 stores the backup configuration 350 for IFD2 310; IFD2 310 stores the backup configuration 355 for EFD3 315; and IFD3 315 stores the backup configuration 360 for EFDl 305. Each EFD can also store software to automatically reload the respective backup configuration when necessary In another implementation, an IFD may store backup configurations for multiple IFDs, and the backup configuration for an IFD may be stored on multiple IFDs

The system 300 may also include a gateway connection 320 to either the Internet or a stand-alone local area network such as an Intranet. The gateway connection 320 may include browser software 321 for browsing network web sites, such as web sites that may be found on the World Wide Web The Internet/Intranet gateway 220 can be connected to any IFD on the network. In Fig 3, the Internet/Intranet gateway 320 is connected to IFDl 305 In some implementations, the Internet/Intranet gateway 320 may provide access to the World Wide Web, thus allowing any web site that contains IFD configuration information to be visited A web site may even be developed specifically for the purpose of stonng and/or supplying IFD configurations. In this manner, a web server can act as a configurator. Refernng also to Fig. 4, the use of a web site as a configurator allows this approach to be used in implementations in which the IFDs do not use resident configurator software. The Internet/Intranet gateway 320 can be used to perform the initial generation of an

IFD configuration, which may be required when a new IFD is introduced into the system, when an existing IFD requires an update to its configuration, or when a power outage or other event affects all of the IFDs so that they all require configuration reloading. In some implementations, the ability to access the Internet via Web browser software 321 provides system redundancy for configurators as well as backup versions of specific configurations.

Refernng to Fig. 5, another implementation of a peer-to-peer hosting system 500 uses a network-based approach. The system 500 includes three exemplary EFDs: IFDl 505, IFD2 510, and IFD3 515. Again, the system 500 can easily be adapted to include as many EFDs as desired. The system 500 also includes a network server 520 with a permanent Internet/Intranet gateway connection 525, including browser software 527. This arrangement provides a robust network design, much like a typical local area network (LAN) or wide area network (WAN). In the system 500, the Internet/Intranet gateway connection 525 allows the configurations to be restored via the gateway 525 for any contingency, so that the configurations can be restored either via the gateway 525 or via the backup configurations 560, 565, 570 stored on corresponding peer devices. Additionally, the backup configurations may be stored on the network server 520, thus providing a third possible source for restonng configurations. Referring to Fig. 6, in a variation of the implementation illustrated in Fig. 5, the system 500 may still use a network-based approach, but, because it uses an industrial protocol that supports peer-to-peer functionality but is not designed for use with the Internet, such as Foundation Fieldbus or PROFIBUS, there is no gateway connection 525. Despite this, the network-based approach still provides the ability to restore the IFD configurations either from the backup versions on corresponding peer devices via the network server 520, or directly from the network server 520 itself.

This implementation also functions in the absence of resident Java applet configurators by using a configurator 605 that is contained within the network server 520. Once again, system redundancy for both the configurator function and the backup of specific individual configurations is provided, in this instance via the network server 520 and its associated configurator 605.

Referring to Fig. 7, in another variation of the implementations illustrated in Figs. 5 and 6, the system 500 may still use a network-based approach while using an industrial protocol that is not designed for use with the Internet, such as HART, FoxComm, Foundation

Fieldbus, or PROFIBUS. Instead of direct access to the Web via browser software 527, the gateway connection 525 contains protocol translation software 705 that translates communications between an Internet-compatible protocol and the local industrial protocol. This variation thus provides the ability to use the Internet as either a configurator or to store backup configurations even when the local protocol does not support Internet communications.

Referring to Figs. 6 and 7, another variation allows the network-based approach to be used even if the local industrial protocol (e.g., HART or FoxComm) does not support peer- to-peer functionality. Thus, in this variation, backup configurations are not stored on peer IFDs. However, configurations can still be provided or restored either by using configurator software 605 that is resident on the network server 520, as shown in Fig. 6, or by using configurator software stored on a web server and accessed via the gateway connection 525, the protocol translation software 705, and the browser software 527, as shown in Fig. 7. Referring to Fig. 8, an IFD in a system using the peer-to-peer hosting method may operate according to a procedure 800. Initially, the EFD checks whether it is configured (step

805). If the EFD is configured, the IFD proceeds with normal operations (step 810). The IFD continues with normal operations until a failure, activation of the configurator, or some other event causes the IFD to cease normal operations.

If the IFD is not configured, the IFD will request a copy of its configuration from one or more peer devices (step 815). The request may be directed, for example, to a particular peer IFD, the identity of which is pre-loaded in the IFD. The request also may be a broadcast request directed to all peer IFDs.

In general, an IFD will receive a configuration from a peer IFD when the IFD has previously lost its configuration due to device failure or replacement, or due to a localized loss of power. When an IFD is connected to the network for the first time, there will not be a backup configuration available for that IFD. However, in some implementations, the IFD may still receive a configuration from a peer IFD. For example, a system may employ a standard configuration for a certain class of IFDs (e.g., pressure sensors), and the IFD may receive a configuration for the class to which it belongs.

If the IFD does not immediately receive a copy of its configuration (step 820), the IFD checks to see whether its configurator has been activated (step 825). The configurator may be activated, for example, by a Web browser connected to the EFD or the network including the IFD, by a hand-held device or computer connected to the IFD, or by manipulation of a button or switch mounted on the EFD.

If the configurator has been activated, the EFD generates a configuration using the configurator (step 830). After the configuration is generated, the IFD stores the configuration (step 835) and transmits a backup copy of the configuration to one or more other IFDs (step 840). The EFD then confirms that the configuration is complete (step 805) and begins normal operations (step 810).

If the configurator has not been activated (step 825), the IFD cycles through a loop that checks for receipt of a configuration (step 820) or activation of the configurator (step

825). The IFD continues to do this until one of these events occurs.

If a configuration is received from a peer IFD (step 820), the IFD stores the configuration (step 835). Storage of the configuration may include storage of a backup configuration for the peer EFD transmitted by the peer EFD along with the requested configuration. After storing the configuration, the EFD may optionally transmit a backup copy of its configuration for storage at one or more peer EFDs (step 840). The IFD then confirms that the configuration is complete (step 805) and begins normal operations (step 810).

Upon completion of normal operations, the IFD cheeks to see if the configurator has been activated (step 845). If so, the IFD generates a revised configuration using the configurator (step 830) and proceeds as discussed above. If not, the IFD verifies that it is still configured (step 805) and proceeds accordingly.

Other embodiments are within the scope of the following claims.

What is claimed is:

Claims

1. A method of storing device configurations in a system including at least two interconnected intelligent field devices (IFDs), the method comprising: providing at least two IFDs; providing a communications connection between the IFDs; storing a configuration for a first IFD in the first IFD; and storing a backup of the configuration for the first IFD in at least one other IFD.

2. The method of claim 1, wherein storing a configuration for the first IFD comprises: the first IFD requesting a configuration from at least one other IFD using the communications connection; an IFD having a stored backup of the configuration for the first IFD transmitting the backup to the first IFD using the communications connection; and the first IFD receiving the transmitted backup and storing the received backup in the first IFD as the configuration for the first IFD.

3. The method of claim 2, wherein storing a backup of the configuration for the first IFD comprises: the first EFD transmitting a backup of the configuration for the first EFD to at least one other EFD using the communications connection; and the at least one other IFD receiving and storing the backup of the configuration.

4. The method of claim 1, wherein storing a backup of the configuration for the first IFD comprises: the first IFD transmitting a backup of the configuration for the first EFD to at least one other IFD using the communications connection; and the at least one other EFD receiving and storing the backup of the configuration.

5. The method of claim 1, wherein the configuration includes instructions regarding the initial settings of the IFD and the manner in which the IFD should respond to particular events.

6. The method of claim 1, wherein storing a configuration for the first IFD comprises generating the configuration using a configurator program and storing the generated configuration.

7. The method of claim 6, wherein the configurator program is stored in the first IFD.

8. The method of claim 7, wherein the configurator program comprises a Java applet.

9. The method of claim 7, further comprising accessing the configurator program using a Web browser.

10. The method of claim 9, wherein the Web browser is not stored in the first IFD.

11. The method of claim 10, wherein the Web browser is stored in a device connected to the communications connection and the Web browser accesses the configurator program through the communications connection.

12. The method of claim 10, wherein the Web browser accesses the configurator program through a wireless connection between a device on which the Web browser is stored and the first IFD.

13. The method of claim 12, wherein the wireless connection comprises an infrared connection.

14. The method of claim 12, wherein the device comprises a personal digital assistant.

15. The method of claim 12, wherein the device comprises a portable computer.

16. The method of claim 6, wherein the configurator program is stored on a Web site.

17. The method of claim 6, wherein a Web browser is used to access the configurator program.

18. The method of claim 6, wherein an Internet gateway component is used to access the configurator program by translating Internet-compatible communications into a protocol being used by the at least two IFDs.

19. The method of claim 1, wherein storing the backup of the configuration for the first IFD comprises storing the backup in at least two other IFDs.

20. The method of claim 1, wherein each IFD includes at least a sensor for sensing a process condition or a mechanism for controlling a process condition.

21. The method of claim 1 , wherein the communications connection comprises a two- wire connection between the EFDs.

22. The method of claim 21 , further comprising providing operating power to at least the first IFD through the two-wire connection.

23. A network of intelligent field devices, the network comprising: at least two interconnected intelligent field devices (IFDs); a communications connection between the IFDs; a configuration for a first IFD stored in the first IFD; and a backup of the configuration for the first IFD stored in a second IFD.

24. The device network of claim 23, wherein the first IFD is configured to request a configuration from the second IFD using the communications connection, the second IFD is configured to transmit the backup to the first IFD using the communications connection, and the first IFD is configured to receive the transmitted backup and to store the received backup in the first IFD as the configuration for the first IFD.

25. The device network of claim 24, wherein the first EFD is configured to transmit a backup of the configuration for the first IFD to at least the second IFD using the communications connection, and the second IFD is configured to receive and store the backup of the configuration.

26. The device network of claim 23, wherein the first EFD is configured to transmit a backup of the configuration for the first IFD to at least the second EFD using the communications connection, and the second IFD is configured to receive and store the backup of the configuration.

27. The device network of claim 23, wherein the configuration includes instructions regarding the initial settings of the IFD and the manner in which the EFD should respond to particular events.

28. The device network of claim 23, further comprising a configurator operable to generate the configuration.

29. The device network of claim 28, wherein the configurator comprises a program stored in the first IFD.

30. The device network of claim 29, wherein the configurator program comprises a Java applet.

31. The device network of claim 29, wherein the configurator program is configured to be accessed using a Web browser.

32. The device network of claim 31 , wherein the Web browser is stored remotely from the first IFD, the network comprising a connection to the Web browser.

33. The device network of claim 32, wherein the Web browser is stored in a device connected to the communications connection and is configured to access the configurator program through the communications connection.

34. The device network of claim 32, wherein the Web browser is configured to access the configurator program through a wireless connection between a device on which the Web browser is stored and the first IFD.

35. The device network of claim 34, wherein the wireless connection comprises an infrared connection.

36. The device network of claim 34, wherein the device on which the Web browser is stored comprises a personal digital assistant.

37. The device network of claim 34, wherein the deyice on which the Web browser is stored compnses a portable computer

38 The device network of claim 28, wherein the configurator program is stored on a Web site.

39. The device network of claim 28, wherein the configurator program is configured to be accessed using a Web browser.

40. The device network of claim 28, further compπsing an Internet gateway component for use in accessing the configurator program by translating Internet-compatible communications into a protocol being used by the first EFD.

41. The device network of claim 23, further comprising a third EFD and a second backup of the configuration for the first EFD, the second backup being stored in the third IFD.

42. The device network of claim 23, wherem each EFD includes at least a sensor for sensing a process condition or a mechanism for controlling a process condition.

43. The device network of claim 23, wherein the communications connection comprises a two-wire connection between the IFDs.

44. The device network of claim 43, wherein the two-wire connection is connected to provide operating power to at least the first EFD.

45. Software, residing on a processor-readable medium, for storing device configurations in a system including at least two intelligent field devices (IFDs) interconnected by a communications connection between the IFDs, the software comprising instructions for causing the system to: store a configuration for a first IFD in the first IFD; and store a backup of the configuration for the first IFD in at least one other IFD.

46. A method of installing a device configuration on an intelligent field device (IFD), the method comprising: storing a configurator program on the IFD; using an external processor to access the configurator program; running the configurator program on the external processor to generate the device configuration; transmitting the device configuration to the IFD; and storing the device configuration in memory in the IFD.

47. The method of claim 46, wherein the configurator program comprises a Java applet.

48. The method of claim 46, wherein the external processor comprises a personal computer.

49. The method of claim 46, wherein the external processor comprises a hand-held device.

50. A method of installing a device configuration on an EFD, the method comprising: storing a configurator program on a distributed network site; accessing the configurator program using browser software; running the configurator program to generate the device configuration; and storing the device configuration in memory in the IFD. 51 The method of claim 50, wherein the distnbuted network site compnses a World Wide Web site.

52 The method of claim 51 , further compπsmg translating communications between a protocol used by the distnbuted network site and a protocol used by the IFD