Approach for collecting and reporting status data from network devices

FIELD OF THE INVENTION

0001The present invention relates to network devices. The invention more specifically relates to collecting and reporting status data from network devices.

BACKGROUND

0002The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section may not be prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.

0003Some types of network devices are configured to provide status information. For example, some network devices are configured to provide information about firmware versions or communications protocols supported by the network devices. Other network devices, such as multifunction peripherals (MFPs) are configured to provide status information relating to consumables, such as paper, toner and staple levels, service calls and meter readings. As used herein, the term “MFP” refers to a single device that performs several functions. Example functions include, without limitation, printing, scanning, faxing and copying.

0004Status data is typically reported to different recipient devices, such as manufacturer servers and various vendor servers, to be used in a variety of ways. For example, a manufacturer or vendor may use network device status data to identify network devices that need to have a firmware update. As another example, a manufacturer or vendor may use status data from MFPs to provide billing services, to arrange for re-supplying of consumables or to arrange for service calls.

0005One issue with collecting and reporting status data from network devices is how status data is reported to different types of recipient devices that support different data formats and/or communications protocols. It is not uncommon for a vendor enterprise resource planning (ERP) site to implement a proprietary data format or communications protocol. For example, suppose that a first vendor server supports a first data format while a second vendor server supports a second data format that is different than the first data format. A network device that reports status data directly to both the first and second vendor servers must be configured to support both the first and second data formats. Configuring each network device to support multiple data formats and communications protocols is impractical, particularly for large deployments. Furthermore, data formats and communications protocols supported by recipient devices may change over time. For example, suppose that a particular vendor decides to implement a new data format on its vendor server. All network devices that provide report data to the particular vendor's server must be updated to provide report data in the new data format. Thus, even a single change in the data format or communications protocol of a recipient device may require updating a large number of network devices. The large number of data formats and communications protocols supported by recipient devices makes this approach impractical for large deployments.

0006Sometimes intermediary devices are used to collect status data from multiple network devices and then report the status data to recipient devices. For example, in large corporate deployments, it is not uncommon for status data servers to be used to collect status data from sets of network devices and then report the status data to recipient devices. Using status data servers to collect and report status data reduces the number of devices that must be configured to support the data formats and communications protocols of recipient devices, but does not adequately address the problem since many status data servers may still be required in large deployments.

0007In view of the forgoing, there is a need for an approach for collecting and reporting network device status data that does not suffer from limitations of the prior approaches.

SUMMARY

0008An approach is provided for collecting and reporting network device status data. The approach may include aggregating status data from several network devices so that the report data reflects status data from several network devices. The approach also includes formatting and translating data between one or more formats supported by the network devices, from which the status data was collected, and one or more formats supported by recipient devices to which the status data is reported. Status data and/or report data may be stored and report data provided to recipient devices based upon a specified time schedule.

0009According to one aspect of the invention, an apparatus comprises a conversion mechanism configured to process network device status data that conforms to a first format and is received by the apparatus. The conversion mechanism is also configured to generate, based upon the status data, report data that conforms to a plurality of formats supported by a plurality of recipient devices.

BRIEF DESCRIPTION OF THE DRAWINGS

0010The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

0011<figref idref="DRAWINGS">FIG. 1A</figref> is a block diagram that depicts a network architecture for collecting and reporting network device status data in accordance with an embodiment of the invention.

0012<figref idref="DRAWINGS">FIG. 1B</figref> is a block diagram that depicts an architecture where a gateway receives status data from a status data server.

0013<figref idref="DRAWINGS">FIG. 2A</figref> is a block diagram that depicts a network architecture for collecting and reporting network device status data in accordance with another embodiment of the invention.

0014<figref idref="DRAWINGS">FIG. 2B</figref> is a block diagram that depicts an example embodiment of a gateway.

0015<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram that depicts an approach for collecting and reporting network device status data according to an embodiment of the invention.

0016<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram of a computer system on which embodiments of the invention may be implemented.

DETAILED DESCRIPTION

0017In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention. Various aspects of the invention are described hereinafter in the following sections:

I. OVERVIEW

II. ARCHITECTURE

III. FUNCTIONAL OVERVIEW

IV. FORMATTING AND SECURITY

V. OPERATIONAL EXAMPLE

VI. IMPLEMENTATION MECHANISMS

0000I. Overview

0024An approach is provided for collecting and reporting network device status data. The status data may be collected directly from network devices or via an intermediate device, such as a status data server, that collects the status data from network devices. The approach may include aggregating status data from several network devices so that the report data reflects status data from several network devices. The approach also includes formatting and translating data between one or more formats supported by the network devices, from which the status data was collected, and one or more formats supported by recipient devices to which the status data is reported. Status data and/or report data may be stored and report data provided to recipient devices based upon a specified time schedule. The approach is applicable to any type of status data, which may vary depending upon the particular network devices involved. Examples of status data include, without limitation, firmware versions, communications protocols supported by a network device, consumables, such as paper, toner and staple levels, service calls and meter readings.

0000II. Architecture

0025<figref idref="DRAWINGS">FIG. 1A</figref> is a block diagram that depicts a network architecture <b>100</b> for collecting and reporting network device status data in accordance with an embodiment of the invention. Architecture <b>100</b> includes a group of network devices <b>102</b>, <b>104</b>, <b>106</b>, a group of recipient devices <b>108</b>, <b>110</b>, <b>112</b>, a gateway <b>114</b> and links <b>116</b>, <b>118</b>. Network devices <b>102</b>, <b>104</b>, <b>106</b> may be any type of network device to which status data may apply. Examples of network devices <b>102</b>, <b>104</b>, <b>106</b> include without limitation, copiers, printers, facsimile machines, scanners, multi-function peripherals, computers, workstations, client devices, servers and routers. Recipient devices <b>108</b>, <b>110</b>, <b>112</b> may be any type of network device for receiving network device status data. Examples of recipient devices <b>108</b>, <b>110</b>, <b>112</b> include without limitation, computers, workstations and servers.

0026Links <b>116</b>, <b>118</b> may be implemented using any medium or mechanism for exchanging data between network devices <b>102</b>, <b>104</b>, <b>106</b>, gateway <b>114</b> and recipient devices <b>108</b>, <b>110</b>, <b>112</b>. Examples of links <b>116</b>, <b>118</b> include, without limitation, one or more wired or wireless local area networks (LANs), wide area networks (WANs), the Internet, one or more wired or wireless connections, or any combination thereof.

0027Gateway <b>114</b> may be implemented using any mechanism, apparatus or process for performing the functions described herein. Gateway <b>114</b> may be implemented using hardware, software, or any combination of hardware and software. Gateway <b>114</b> does not necessarily have to perform functionality performed by conventional gateways and any type of intermediary device or mechanism may be used. Although embodiments of the invention are depicted in the figures and described herein in the context of a single gateway <b>114</b>, multiple gateways may be used to perform the functions described herein. For example, multiple gateways and a load balancing mechanism may be used to provide additional processing capabilities.

0000Functional Overview

0028Gateway <b>114</b> is configured generally to process status data from network devices <b>102</b>, <b>104</b>, <b>106</b> and generate and provide report data to recipient devices <b>108</b>, <b>110</b>, <b>112</b>. Gateway <b>114</b> may obtain status data directly from network devices <b>102</b>, <b>104</b>, <b>106</b>. Gateway <b>114</b> may query network devices <b>102</b>, <b>104</b>, <b>106</b> for status data or network devices <b>102</b>, <b>104</b>, <b>106</b> may provide status data to gateway <b>114</b> on their own. Gateway <b>114</b> may receive status data from network devices <b>102</b>, <b>104</b>, <b>106</b> asynchronously or according to a specified schedule. According to one embodiment of the invention, gateway <b>114</b> collects status data from network devices <b>102</b>, <b>104</b>, <b>106</b> using the simple network management protocol (SNMP). The invention, however, is not limited to using SNMP for this purpose, and any communications protocol may be used.

0029Instead of receiving status data directly from network devices <b>102</b>, <b>104</b>, <b>106</b>, gateway <b>114</b> may receive status data from an intermediate entity. <figref idref="DRAWINGS">FIG. 1B</figref> is a block diagram that depicts an architecture <b>150</b> where gateway <b>114</b> receives status data from a status data server <b>120</b>. Status data server <b>120</b> is an apparatus, mechanism or process configured to collect status data from network devices <b>102</b>, <b>104</b>, <b>106</b>. Status data server <b>120</b> may use any communications protocol to communicate with network devices <b>102</b>, <b>104</b>,<b>106</b>, depending upon the requirements of a particular application. For example, status data server <b>120</b> may use SNMT or any other suitable communications protocol to communicate with network devices <b>102</b>, <b>104</b>, <b>106</b>. In this arrangement, gateway <b>114</b> generates report data based upon status data received from status data server <b>120</b>. Network devices <b>102</b>, <b>104</b>, <b>106</b> may provide status data to status data server <b>120</b> asynchronously or according to specified times. Alternatively, Status data server <b>120</b> may query status data from network devices <b>102</b>, <b>104</b>, <b>106</b>.

0030Gateway <b>114</b> may provide report data to recipient devices <b>108</b>, <b>110</b>, <b>112</b> asynchronously or according to a specified schedule. The report data may be generated based upon status data from any number of network devices. For example, gateway <b>114</b> may generate report data that reflect status data from one or more of network devices <b>102</b>, <b>104</b>, <b>106</b>. Thus, gateway <b>114</b> may aggregate status data from multiple network devices <b>102</b>, <b>104</b>, <b>106</b>. According to one embodiment of the invention, network device status data includes identification data that identifies an intended recipient of the network device status data. The identification data is used to route the network device status data to a particular recipient device. For example, suppose that gateway <b>214</b> receives particular network device status data from status data server <b>220</b> that contains identification data identifying ERP System B <b>210</b> as the intended recipient. As part of its processing, gateway <b>214</b> parses the particular status data to retrieve the identification data. For example, gateway <b>214</b> may parse extensible markup language (XML) data to locate an XML tag associated with identification data. Gateway <b>214</b> examines the identification data to determine at ERP System B <b>210</b> is the intended recipient of the report data and routes the report data to ERP System B <b>210</b>.

0031According to another embodiment of the invention, gateway <b>214</b> is configured to check for a confirmation receipt from a recipient device and if a confirmation receipt is not received, to generate and provide a notification of the condition. For example, suppose that gateway <b>214</b> provides report data to ERP System C <b>212</b>. If, after a specified time, gateway <b>214</b> has not received confirmation that the report data was received by ERP System C <b>212</b>, then gateway <b>214</b> generates and sends a notification, for example, to administrative personnel.

0032Gateway <b>114</b> may also be configured with local storage for storing status data received from network devices <b>102</b>, <b>104</b>, <b>106</b> or status data server <b>120</b>. The local storage may also be used to store report data generated by gateway <b>114</b>. This allows gateway <b>114</b> to generate report data and then deliver the report data to recipient devices <b>108</b>, <b>110</b>, <b>112</b> at a later time.

0000IV. Formatting and Security

0033The format of status data supported by network devices <b>102</b>, <b>104</b>, <b>106</b> or status data server <b>120</b>, depending upon how gateway <b>114</b> receives the status data, may be different than the format of report data that is provided to recipient devices <b>108</b>, <b>110</b>, <b>112</b>. According to one embodiment of the invention, gateway <b>114</b> is configured to provide a wide variety of data formatting. For example, referring to <figref idref="DRAWINGS">FIG. 1A</figref>, suppose that gateway <b>114</b> receives status data from network device <b>102</b> in XML format. Suppose further that recipient device <b>108</b> supports data in XML format, but uses a different XML schema than network device <b>102</b>. In this situation, gateway <b>114</b> is configured to process the XML status data received from network device <b>102</b> that conforms to the XML schema supported by network device <b>102</b> and generate XML report data that conforms to the XML schema supported by recipient device <b>108</b>. As another example, gateway <b>114</b> may process the XML status data received from network device <b>102</b> and generate report data that conforms to a non-XML format supported by recipient device <b>108</b>. Gateway <b>114</b> may provide report data in different formats to different recipients. For example, gateway <b>114</b> may generate first report data that conforms to a first format supported by recipient device <b>108</b> and also generate second report data that conforms to a second format supported by recipient device <b>110</b>, where the first and second formats are different.

0034Gateway <b>114</b> may also be configured to provide security in applications where security is desired. Network devices <b>102</b>, <b>104</b>, <b>106</b> and status data server <b>120</b> may be configured to provide status data to gateway <b>114</b> using secure communications or a secure communications protocol. According to one embodiment of the invention, gateway <b>114</b> is configured to process report data from network devices <b>102</b>, <b>104</b>, <b>106</b> and status data server <b>120</b> that conforms to a particular security format or protocol. For example, suppose that status data server <b>120</b> is configured to encrypt status data sent to gateway <b>114</b> over link <b>122</b>. In this situation, gateway <b>114</b> is configured to decrypt the status data received from status data server <b>120</b> to recover the original status data and then generate report data based upon the original status data. As another example, gateway <b>114</b> may be configured to support a secure Internet protocol, such as HTTPS, or one or more virtual private networks (VPNs).

0035Gateway <b>114</b> may also be configured to provide report data in a secure manner to recipient devices <b>108</b>, <b>110</b>, <b>112</b>. This may include, for example, encrypting report data to be sent to recipient devices <b>108</b>, <b>110</b>, <b>112</b> and/or using a secure communications protocol, such as HTTPS.

0000V. Operational Example

0036An operational example is now described with reference to <figref idref="DRAWINGS">FIGS. 2 and 3</figref>. <figref idref="DRAWINGS">FIG. 2A</figref> is a block diagram that depicts and arrangement <b>200</b> for collecting and reporting network device status data in accordance with an embodiment of the invention. Architecture <b>200</b> includes a printer <b>202</b>, a copier <b>204</b>, an MFP <b>206</b>, an ERP System A <b>208</b>, an ERP System B <b>210</b>, an ERP System C <b>212</b>, a gateway <b>214</b>, a status data server <b>220</b> and links <b>216</b>, <b>218</b>, <b>222</b>. ERP System A <b>208</b>, ERP System B <b>210</b> and ERP System C <b>212</b> may be implemented at manufacturer or dealer sites.

0037<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram <b>300</b> that depicts an approach for collecting and reporting network device status data according to an embodiment of the invention. In step <b>302</b>, status data server <b>220</b> collects status data from printer <b>202</b>, copier <b>204</b> and MFP <b>206</b>. Status data server <b>220</b> may collect status data from printer <b>202</b>, copier <b>204</b> and MFP <b>206</b> according to a specified schedule or at random times. Furthermore, status data server <b>220</b> may collect status data from printer <b>202</b>, copier <b>204</b> and MFP <b>206</b> at the same time or at different times, depending upon the requirements of a particular application. Status data server <b>220</b> may collect status data from printer <b>202</b>, copier <b>204</b> and MFP <b>206</b> using any type of communications protocol.

0038In step <b>304</b>, status data server <b>220</b> formats the status data collected from printer <b>302</b>, copier <b>304</b> and MFP <b>206</b>. For example, status data server <b>220</b> may format the data using XML, comma separated values (CSV), or any other suitable format, depending upon the requirements of a particular application. Status data server <b>220</b> may also encrypt the formatted status data, for example, using a proprietary algorithm or a public key associated with status data server <b>220</b>.

0039In step <b>306</b>, status data server <b>220</b> provides the formatted (and possibly encrypted) status data to gateway <b>214</b> over link <b>222</b>. Status data server <b>220</b> may provide the formatted status data to gateway <b>214</b> using a variety of techniques, depending upon the requirements of a particular application. For example, status data server <b>220</b> may provide the formatted status data to gateway <b>214</b> in a message, in an email, or as an email attachment. If the status data is formatted using XML, then the status data may be provided to gateway <b>214</b> as an email attachment. Status data server <b>220</b> may use any type of communications protocol to communicate the status data to gateway <b>214</b> over link <b>222</b>. SMTP, HTTP, HTTPS and FTP are all example communications protocols that status data server may use for this purpose.

0040In step <b>308</b>, gateway <b>214</b> receives the status data from status data server <b>220</b> and generates report data that conforms to the format required by the recipient device, i.e., ERP System A <b>208</b>, ERP System B <b>210</b> and ERP System C <b>212</b>. For example, suppose that gateway <b>214</b> receives status data from status data server <b>220</b> in the form of an email with an encrypted XML attachment that contains status data that specifies a meter reading for MFP <b>206</b>. Suppose further that this status data is to be reported to ERP System A <b>208</b> that supports a comma separated data file format. Gateway <b>114</b> decrypts the XML attachment and generates a comma separate data file based upon the XML data contained in the attachment. Gateway <b>114</b> may also encrypt the comma separated file if required by ERP System A <b>208</b>.

0041In step <b>310</b>, gateway <b>214</b> provides the formatted report data to the recipient device. In the present example, gateway <b>214</b> provides the comma separated file to ERP System A <b>208</b> over link <b>218</b>.

0042<figref idref="DRAWINGS">FIG. 2B</figref> is a block diagram that depicts an example embodiment of gateway <b>214</b>. As depicted in <figref idref="DRAWINGS">FIG. 2B</figref>, gateway <b>214</b> includes a conversion mechanism <b>250</b> and a non-volatile storage <b>252</b>. Gateway <b>214</b> may include other modules and elements, depending upon the requirements of a particular application, and <figref idref="DRAWINGS">FIG. 2B</figref> is not meant to depict all of the modules or elements that may be included in gateway <b>214</b>. Conversion mechanism <b>250</b> is configured to process status data received from status data server <b>220</b> and generate report data to be provided to ERP System A <b>208</b>, ERP System B <b>210</b> and ERP System C <b>212</b>. As described herein, this may include parsing and converting the format of status data received from status data server <b>220</b> from a format supported by status data server <b>220</b> into a format supported by ERP System A <b>208</b>, ERP System B <b>210</b> and ERP System C <b>212</b>. Gateway <b>214</b> may also be configured to decrypt status data received from status data server <b>220</b> and encrypt report data to be provided to ERP System A <b>208</b>, ERP System B <b>210</b> and ERP System C <b>212</b>. Conversion mechanism may be implemented by hardware, software, or any combination of hardware and software. Conversion mechanism <b>250</b> may be implemented as one or more multi-threaded processes executing on any number of computing architectures to increase the amount of status data that can be processed simultaneously. Gateway <b>214</b> may also be configured to support queuing of messages received from status data server <b>220</b>. This allows conversion mechanism <b>250</b> to process messages asynchronously, based upon the availability of processing resources.

0043In the present example, gateway <b>214</b> includes configuration data <b>254</b> stored on non-volatile storage <b>252</b> that specifies information needed by conversion mechanism <b>250</b> to perform its functions. For example, configuration data <b>254</b> may include data that specifies data formats supported by status data server <b>220</b> and ERP System A <b>208</b>, ERP System B <b>210</b> and ERP System C <b>212</b>. Configuration data <b>254</b> may also specify how data can be converted from one format to another format. For example, configuration data <b>254</b> may specify that a particular transform is to be used to convert data from a first data format supported by status data server <b>220</b> to a second data format supported by ERP System A <b>208</b>. When a change is made to a data format or communications protocol supported by status data server <b>220</b> or ERP System A <b>208</b>, ERP System B <b>210</b> and ERP System C <b>212</b>, configuration data <b>254</b> is updated to reflect the change. This reduces the number of devices that need to be updated when formatting or communications protocol changes are made. Non-volatile storage may also include status data <b>258</b> received from status data server <b>220</b> or other sources, as well as report data generated by conversion mechanism <b>250</b>. This allows report data <b>256</b> to be generated from status data <b>258</b> at any time and then delivered to a recipient device, such as ERP System A <b>208</b>, at a later time.

0000VI. Implementation Mechanisms

0044Although embodiments of the invention have been described herein in the context of status data being processed through a gateway, the invention does not require that all network device status data be processed through a gateway. For example, in <figref idref="DRAWINGS">FIG. 2A</figref>, status data server <b>220</b> may, in addition to providing status data to gateway <b>214</b>, provide status data directly to other recipient devices, e.g., an ERP System D (not depicted). Thus, the approach may be used in combination with network devices and intermediary devices, such as status data server <b>220</b>, that provide status data directly to recipient devices.

0045The fuctionality performed by the gateways described herein may be implemented using a wide variety of approaches, depending upon the requirements of a particular application. For example, any type of hardware, software or hardware/software combination may be used. Also, any type of computing platform may be used.

0046<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram that illustrates a computer system <b>400</b> upon which an embodiment of the invention may be implemented. Computer system <b>400</b> includes a bus <b>402</b> or other communication mechanism for communicating information, and a processor <b>404</b> coupled with bus <b>402</b> for processing information. Computer system <b>400</b> also includes a main memory <b>406</b>, such as a random access memory (RAM) or other dynamic storage device, coupled to bus <b>402</b> for storing information and instructions to be executed by processor <b>404</b>. Main memory <b>406</b> also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor <b>404</b>. Computer system <b>400</b> further includes a read only memory (ROM) <b>408</b> or other static storage device coupled to bus <b>402</b> for storing static information and instructions for processor <b>404</b>. A storage device <b>410</b>, such as a magnetic disk or optical disk, is provided and coupled to bus <b>402</b> for storing information and instructions.

0047Computer system <b>400</b> may be coupled via bus <b>402</b> to a display <b>412</b>, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device <b>414</b>, including alphanumeric and other keys, is coupled to bus <b>402</b> for communicating information and command selections to processor <b>404</b>. Another type of user input device is cursor control <b>416</b>, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor <b>404</b> and for controlling cursor movement on display <b>412</b>. This input-device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

0048The invention is related to the use of computer system <b>400</b> for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system <b>400</b> in response to processor <b>404</b> executing one or more sequences of one or more instructions contained in main memory <b>406</b>. Such instructions may be read into main memory <b>406</b> from another machine-readable medium, such as storage device <b>410</b>. Execution of the sequences of instructions contained in main memory <b>406</b> causes processor <b>404</b> to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

0049The term “machine-readable medium” as used herein refers to any medium that participates in providing data that causes a machine to operation in a specific fashion. In an embodiment implemented using computer system <b>400</b>, various machine-readable media are involved, for example, in providing instructions to processor <b>404</b> for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device <b>410</b>. Volatile media includes dynamic memory, such as main memory <b>406</b>. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus <b>402</b>. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infrared data communications.

0050Common forms of machine-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

0051Various forms of machine-readable media may be involved in carrying one or more sequences of one or more instructions to processor <b>404</b> for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system <b>400</b> can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector can receive the data carried in the infrared signal and appropriate circuitry can place the data on bus <b>402</b>. Bus <b>402</b> carries the data to main memory <b>406</b>, from which processor <b>404</b> retrieves and executes the instructions. The instructions received by main memory <b>406</b> may optionally be stored on storage device <b>410</b> either before or after execution by processor <b>404</b>.

0052Computer system <b>400</b> also includes a communication interface <b>418</b> coupled to bus <b>402</b>. Communication interface <b>418</b> provides a two-way data communication coupling to a network link <b>420</b> that is connected to a local network <b>422</b>. For example, communication interface <b>418</b> may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface <b>418</b> may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface <b>418</b> sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

0053Network link <b>420</b> typically provides data communication through one or more networks to other data devices. For example, network link <b>420</b> may provide a connection through local network <b>422</b> to a host computer <b>424</b> or to data equipment operated by an Internet Service Provider (ISP) <b>426</b>. ISP <b>426</b> in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the “Internet” <b>428</b>. Local network <b>422</b> and Internet <b>428</b> both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link <b>420</b> and through communication interface <b>418</b>, which carry the digital data to and from computer system <b>400</b>, are exemplary forms of carrier waves transporting the information.

0054Computer system <b>400</b> can send messages and receive data, including program code, through the network(s), network link <b>420</b> and communication interface <b>418</b>. In the Internet example, a server <b>430</b> might transmit a requested code for an application program through Internet <b>428</b>, ISP <b>426</b>, local network <b>422</b> and communication interface <b>418</b>.

0055The received code may be executed by processor <b>404</b> as it is received, and/or stored in storage device <b>410</b>, or other non-volatile storage for later execution. In this manner, computer system <b>400</b> may obtain application code in the form of a carrier wave.

0056In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is, and is intended by the applicants to be, the invention is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.