Method and apparatus for providing multiple vendor support to remotely monitored devices

ES 2 279 062 T3

DESCRIPTION

Method and apparatus for providing multi-vendor support to remotely controlled devices.

The present invention relates to the supervision, configuration or installation of physical support in a computer system.

Computer systems generally include hardware and software. The hardware is the actual physical computer installation, while the software is the list of instructions for handling the hardware. Typically, computer systems will include a variety of hardware devices that are interconnected with each other. When the hardware devices are interconnected with each other, the hardware handling software needs to be configured to allow communication between the hardware devices so that the hardware devices can operate cooperatively. It is also desirable that the hardware devices are monitored. For the purposes of discussion, a hardware device that you configure or monitor is referred to as a control device. Also, for purposes of discussion, the hardware device that is configured to operate cooperatively or that is monitored by the control device will be referred to as an interconnect device.

When hardware devices are initially interconnected with each other, it is common for the software that handles the devices to remain unconfigured to allow cooperative operation. Consequently, a significant portion of the installation computer hardware devices collectively configure the software. In some arrangements, a user must manually configure the computer hardware by opening the computer hardware and physically setting jumpers or DIP switches. In still some other arrangements, the installation procedure includes user-loaded software from a floppy disk to configure the hardware devices. Attempts have also been made for computer hardware devices to include software that can automatically configure hardware devices. However, there are some obvious disadvantages and shortcomings with respect to the approaches identified above.

One disadvantage is that self-installing hardware software is restrictive in its ability to accommodate new devices or new manufacturers that have not been specifically programmed into the software. In the prior art, if the control device does not recognize the specific model of the interconnect device, automatic configuration is not possible. In other words, if the control device is not programmed to predict the pattern of an interconnect device, then the automatic configuration of the hardware will not be successful. In such a circumstance, a user will have to manually install the configuration media on the hardware devices.

Another disadvantage of the prior art is that the control device is unable to partially configure hardware devices if the particular model of the interconnect device cannot be identified. In other words, if a control device cannot identify a specific model of the interconnect device, then the interconnect device will not be configured to operate cooperatively. This results in the unconfigured interconnect device being inoperative and basically unusable.

It is desirable that hardware devices located on a network be monitored for maintenance, utilization, or other purposes. However, it has been difficult for one control device to communicate with various interconnect devices in a network, due to different means of communication between manufacturers and models of interconnect devices. These disadvantages prevent network administrators from obtaining crucial information about the performance and efficiency of interconnect devices on a network.

Document US6,122,639 discloses a network in which information about devices on the network is collected.

Document US6,349,306 discloses an apparatus and method for monitoring parameters that govern the service characteristics of a network device.

The present invention relates to a method and system intended to monitor at least one device connected to the network (monitored device) using a controller.

In accordance with the present invention, a method is provided for determining whether a monitored device is supported by a monitoring system in a network-based system having the monitoring system and a plurality of monitored devices coupled for communication purposes over a network, the supervision system being coupled for communication purposes to a first and a second database, the procedure comprising the steps of:

(a) query the monitored device to obtain at least one of the manufacturer, model, and a unique identifier of the monitored device;

(b) determining if the monitoring system is configured to interface with the monitored device using information stored in said first database;

ES 2 279 062 T3 (c) determine if the monitored device is supported by the monitoring system using information stored in said second database:

(i) determining whether a manufacturer of the monitored device is supported by the monitoring system;

(ii) obtaining at least one of a serial number or unique identifier from the monitored device if the manufacturer is supported by the monitoring system;

(iii) obtaining a MAC (media access control) address of the monitored device if the manufacturer is not supported by the monitoring system; and (iv) assigning a random number to the unique identifier if the MAC address cannot be obtained from the monitored device.

According to a further aspect of the invention, there is provided an apparatus for monitoring at least one supervised device of a plurality of supervised devices in a network-based system coupled for communication purposes to a network, the apparatus comprising:

a supervision system coupled to the network for communication purposes;

a first and a second database coupled for communication purposes to the supervision system;

means for querying the monitored device to obtain at least one of manufacturer, model, and a unique identifier of the monitored device;

means for determining if the monitoring system is configured to interface with the monitored device using information stored in said first database;

means for determining whether the monitored device is supported by the monitoring system using information stored in said second database;

means for determining whether a manufacturer of the monitored device is supported by the monitoring system;

means for obtaining at least one of a serial number or unique identifier from the monitored device if the manufacturer is supported by the monitoring system;

means for obtaining a MAC address of the monitored device if the manufacturer is not supported by the monitoring system; and means for assigning a random number to the unique identifier if the MAC address cannot be obtained from the monitored device.

In accordance with a further aspect of the invention, a network-based system is provided having a monitored device from among a plurality of devices connected to a network, the system comprising:

a first and a second database coupled for communication purposes to the controller, said second database storing information destined to determine if the monitored device is supported by the controller;

a controller destined to supervise the supervised device, said logic controller having to:

query the monitored device to obtain at least one of manufacturer, model, and a unique identifier of the monitored device;

using a hierarchical procedure to determine if the monitoring system is configured to interface with the monitored device using information stored in the first database; and determine if the monitored device is supported by the monitoring system using information stored in the second database:

(i) determining whether a manufacturer of the monitored device is supported by the monitoring system;

(ii) obtaining at least one of a serial number or unique identifier from the monitored device if the manufacturer is supported by the monitoring system;

(iii) obtaining a MAC address of the monitored device if the manufacturer is not supported by the monitoring system; Y

ES 2 279 062 T3 (iv) assigning a random number to the unique identifier if the MAC address cannot be obtained from the monitored device;

in which configuration information is updated in said first database with information stored in the second database to enable the controller to interface with the monitored device, consequently allowing flexibility to update devices monitored by the monitoring system from among the plurality of devices.

A method and apparatus for providing multi-vendor support to remotely supervised devices is described. The procedure includes querying a monitored device to obtain at least one of manufacturer, model, and a unique identifier of the monitored device, using a hierarchical technique to determine if the monitoring system is configured to interface with the monitored device using information stored in a first database; and determining whether the monitored device is supported by the monitoring system using information stored in a second database. The hierarchical technique includes first determining whether the manufacturer of the monitored device is supported by the monitoring system and then subsequently determining whether the device model is supported by the monitoring system.

In exemplary embodiments of the present invention, a plurality of databases are used to configure devices with systems. These embodiments are advantageous since valuable computer resources are used during initialization of devices with a system, while preserving computer resources during system operation. For example, a system can use two different databases when configuring a device. The first database (i.e., a System Configuration Database) stores information about the device for devices that have already been configured in the system and in which information about the operational status of the devices is stored as that the devices are being monitored by the system. Such information about the device may include the manufacturer's name and model name, while information about the operating status may include the page count and toner level.

Information about the device stored in the first database is used during system initialization, while information about the state stored in the first database is accumulated during system operation. Therefore, the first database will be large, since it will contain information about the state. However, the consumption of computer resources will be of little importance, since the information about the device is used during initialization, while the information about the status is only added when the system is running.

In an exemplary embodiment of the present invention, the system of the present invention also utilizes a second database (ie, a System Support Database). This second database can be relatively extensive, since it would include data referring to a plurality of devices. When a device is initialized with a system and the system is not yet configured to interface with the device, then the first database (that is, the System Configuration Database) can be updated using the information from the second base (that is, the System Support Database), so that the device can interface with the system. Due to the large amount of stored information, querying the second database is not only time-consuming, but also uses a large amount of valuable computer resources. After the critical information (ie protocol) regarding the device in the first database is updated with information from the second database, only the first database is used.

In one aspect, the present invention provides, in a network-based system having a supervision system and a plurality of supervised devices coupled for communication purposes over a network, the supervision system being coupled for first-time communication purposes. and second databases, a procedure to determine if a monitored device is supported by the monitoring system, comprising querying the monitored device to obtain at least one of manufacturer, model, and a unique identifier of the monitored device; determining if the monitoring system is configured to interface with the monitored device using information stored in said first database; and determining whether the monitored device is supported by the monitoring system using information stored in said second database.

The step of determining if the monitoring system is configured to interface with the monitored device is performed by consulting the first database on at least one of manufacturer, model, and a unique identifier obtained from the monitored device. The step of determining whether the monitored device is supported by the monitoring system includes determining whether a manufacturer of the monitored device is supported by the monitoring system and, if true, determining whether a model of the monitored device is supported by the monitoring system. ; and updating the first database with information about the manufacturer and model if the monitored device is supported by the monitoring system, using information stored in the second database.

The above procedure further includes obtaining at least one of a serial number or unique identifier from the monitored device if the manufacturer is supported by the monitoring system; obtain a MAC address of the monitored system if the manufacturer is not supported by the monitoring system; and assigning a random number to the unique identifier if the MAC address cannot be obtained from the monitored device. The proce4

ES 2 279 062 T3 also includes listing the monitored device as generic if the manufacturer of the monitored device is not supported by the monitoring system; obtaining, from the monitored device, information that is common to the plurality of monitored devices, and obtaining information that is common to a plurality of monitored devices of the general manufacturer.

The procedure also includes obtaining unique information from the monitored device if the model of the monitored device is supported by the monitoring system; and obtain information that is common to supervised devices manufactured by the general manufacturer. The first database is a system configuration database comprising information intended to enable communication between the monitoring system and the monitored device; and status information related to the monitored device, the status information being added after initialization of the monitoring system.

The step of determining whether the monitoring system is configured to interface with the monitored device comprises querying the monitored device about data stored in the first database. The first database is a system configuration database and comprises information intended to enable communication between the monitoring system and the monitored device; and status information related to the monitored device, the status information being added upon initialization of the monitoring system to monitor the monitored device. The second database is a system support database and comprises information about various manufacturers and device models supported by the monitoring system.

In another aspect, the present invention provides, in a network-based system having a plurality of supervised devices coupled for communication purposes to a network, an apparatus for supervising at least one supervised device of the plurality of supervised devices, comprising : a supervision system coupled to the network for communication purposes; a first and a second database coupled for communication purposes to the supervision system; means for querying the monitored device to obtain at least one of manufacturer, model, and a unique identifier of the monitored device; means for determining if the monitoring system is configured to interface with the monitored device using information stored in said first database; and means for determining whether the monitored device is supported by the monitoring system using information stored in said second database.

In yet another aspect, the present invention provides a network-based system having a supervision system and a plurality of supervised devices coupled for communication purposes over a network, the supervision system being coupled for communication purposes first and foremost. second databases, a computer program product within a computer usable medium, comprising instructions to query the monitored device to obtain at least one of manufacturer, model, and a unique identifier of the monitored device; instructions for determining whether the monitoring system is configured to interface with the monitored device using information stored in said first database; and instructions for determining whether the monitored device is supported by the monitoring system using information stored in said second database.

In a further aspect, the present invention provides, in a network-based system having a supervised device from among a plurality of devices connected to a network, the system comprising first and second databases coupled for communication purposes to the controller, storing said second information database for determining whether the monitored device is supported by the controller; a controller for supervising the supervised device, said logic controller having to query the supervised device to obtain at least one of manufacturer, model and a unique identifier of the supervised device; using a hierarchical procedure to determine if the monitoring system is configured to interface with the monitored device using information stored in the first database; and determining whether the monitored device is supported by the monitoring system using information stored in the second database; and wherein configuration information in said first database is updated with information stored in the second database to enable the controller to interface with the monitored device, consequently allowing flexibility to update devices monitored by the monitoring system of between the plurality of devices.

An advantage of the present invention includes the ease with which to change the devices that the system supports by modifying the database instead of the system.

A more complete appreciation of the present invention and many of the advantages derived therefrom will be readily obtained as it is better understood by reference to the following detailed description when considered in connection with the accompanying drawings.

Figure 1 is a diagram illustrating the network relationship of device 2 and system 8, in an exemplary embodiment of the present invention.

Figure 2 is an exemplary flow chart illustrating the steps involved in determining whether system 8 is configured to interface with device 2;

Figure 3 is an exemplary flow chart illustrating the steps involved in determining whether system 8 is configured to interface with device 2 using the System Configuration Database 6;

Figure 4 is an exemplary illustration of a hierarchical approach to determining whether device 2 is supported by system 8;

Figure 5 illustrates software objects in an exemplary embodiment of the present invention;

Figure 6 illustrates an exemplary sequence diagram at the time the system is initialized to obtain information about object identifiers used to identify the manufacturer, model, and unique identifier, and to obtain information about the manufacturers and models supported by the system. system;

Figure 7 illustrates an exemplary sequence diagram for creating device objects to represent monitored devices during initialization;

Figure 8 shows the sequence diagram for executing the setAgent () function 122 of VendorModel 118;

Figure 9 is an exemplary flow diagram for the VendorModel setAgent () function;

Figure 10 exemplifies a sequence diagram in which the system obtains information used to obtain the information on the status concerning the specific manufacturer and model of the monitored devices;

Figure 11 shows the flow chart for the DeviceFactory createDevice () function;

Figure 12 shows the sequence diagram for executing the monitorStatus () function;

Figure 13 shows the sequence diagram for executing the function getStatus () 214 of Device () 210;

Figure 14 shows the tables of a database that has information about the manufacturers and models supported by the system;

Figure 15 shows an example of the contents of the database tables as described in Figure 14; and Figure 16 shows the class diagram for the ODBC2 package.

Figure 1 is a diagram illustrating the network relationship of device 2 and system 8. Device 2 interfaces with system 8 through network 4. System 8 is coupled to the System Configuration Database (SCD) 6 and to the System Support Database (SSD) 10. Network 4 can be any type of communication structure that allows device 2 and system 8 to exchange data. For example, network 4 could be either a wide area network (WAN), a local area network (LAN), or a simple cable physically connecting device 2 and system 8. It will be noted that the present invention does not It is restrictive in terms of the type of networks and that other networks can be used to allow communication between device 2 and system 8.

System Configuration Database 6 includes information of the first and second types. The first type of information is device or configuration information, such as, for example, manufacturer's name, model name, IP address, company name, name of contact person, and person's email address. contact, to name a few. Configuration information is used only during system 8 initialization to determine which devices need to be monitored. However, the System Configuration Database 6 does not include information about which protocol to use to communicate with the device 2. However, the SCD 6 includes information necessary for communication, such as, for example, the IP address. Accordingly, SCD 6 contains information that is used to determine if system 8 is configured to interface with device 2. The second type of information stored in SCD 6 is status information. Examples of status information include page count, error status, and toner level. Status information is added to the database (SCD 6) after system 8 initialization when system 8 is monitoring network connected devices 4. The System Configuration Database (SCD 6) is not directly dependent from the System Support Database (SSD 10).

SSD 10 includes information about manufacturers and models that are supported by system 8. Although this system can support all devices regardless of manufacturer or model, the amount of status information obtained from device 2 depends on manufacturers and models that are supported by SSD 10. If the manufacturer and model are supported by SSD 10, then detailed status information can be obtained from device 2. Thus, the SSD 10 determines what type of status information is stored in the System Configuration Database (SCD 6).

Information from both SCD 6 and SSD 10 is used to create device objects to represent the devices being monitored. Although a single device 2 connected to network 4 is shown, it will be noted that a plurality of devices that need to be monitored may be connected to network 4. The objects of

ES 2 279 062 T3 devices allow system 8 to communicate with device 2 and determine what information to obtain from the devices.

Figure 2 is an exemplary flow diagram illustrating how it is determined whether system 8 is configured to interface with device 2. At block 12, system 8 or some other device that is part of network 4 determines if system 8 is configured to interface with device 2. For example, it is determined if system 8 is programmed with software that allows system 8 to communicate with device 2. In other words, system 8 uses a protocol that is compatible with device 2, such that system 8 and device 2 can exchange data and operate cooperatively. To determine if system 8 is configured to interface with device 2, system 8 also obtains configuration information from device 2 and determines if device 2 is supported by system 8.

In block 14, if it is determined that system 8 is configured to interface with device 2, then, in block 20, a communication protocol is established between system 8 and device 2, based on information stored in the Base system support data 10. In block 22, the System Configuration Database (SCD 6) is updated with the configuration data obtained by determining if system 8 was configured to interface with device 2. However, if determined, in block 14, that system 8 is not configured to interface with device 2, then the procedure ends and device 2 will not interface with system 8.

Figure 3 is an exemplary flow chart illustrating how it is determined if system 8 is configured to interface with device 2 using the System Configuration Database (SCD 6). In block 24, device 2 is queried using a standard communication protocol to determine its manufacturer, model and / or unique identification.

In block 26, if the manufacturer, model or unique identification of the device has been determined, the procedure then advances to block 36, or else the procedure advances to block 28. In block 36, it is determined that the system is configured to interface with device 2.

In block 28, device 2 is queried using data stored in the configuration database of system 6 to determine the manufacturer, model and / or unique identification of device 2. In block 34, it is determined if in block 28 The manufacturer, model and / or unique identification of the device has been identified 2. If the determination of block 34 is positive, then, at block 36, it is determined that the system is configured to interface with device 2. If the determination of block 34 is negative, then, at block 38, it is determined that the system is not configured to interface with device 2.

To query device 2 for manufacturer and model information in blocks 24 and 28, the device manufacturer and model are checked against the System Support Database 10 to determine if the manufacturer and model are supported by system 8. However, it does not matter whether or not system 8 is configured to interface with device 2.

The System Support Database 10 is used to determine what status information to obtain from Device 2 as it is monitored by System 8. A device object destined for Device 2 includes information from SSD 10 about what state information obtain. If the device manufacturer and model are not supported on the SSD 10, the device object will then get information about the status that is available for all devices connected to the network 4. If the manufacturer is supported on the SSD 10 but the model device is not supported, the device object will then get status information that is available to all devices from a manufacturer. If the manufacturer and model are supported, the device object will then get status information that is available for all devices in the model.

Figure 4 is an exemplary illustration of a hierarchical approach to determining whether device 2 is supported by system 8. In blocks 56 and 58, it is determined whether the manufacturer of device 2 is supported by system 8. If the manufacturer does not is supported, it is then determined, at block 60, that the device is to be configured to use a generic protocol. If the manufacturer is supported, the procedure then advances to block 62.

In blocks 62 and 64, it is determined if the model of device 2 is supported by system 8. If the model is not supported, then it is determined, in block 66, that device 2 is to be configured using a specific protocol of the system. maker. If the model is supported, it is then determined, at block 68, that device 2 is to be configured using a model specific protocol.

Figure 5 illustrates software objects in an exemplary embodiment of the present invention. The Send Interface Manager software object 70 interfaces directly or indirectly with the DataTransfer 74, ODBC-1 72, DeviceFactory 76, VendorModel 78, ODBC-2 84, SNMP 80 and Device 82 software objects.

ES 2 279 062 T3

Table 1 illustrates the functions of ODBC-1 72.

TABLE 1

<td>updateConfig</td><td>Before this function is invoked, the invocation function should not replace the manufacturer and model inputs if the get functions return a null string from the VendorModel package. This function updates the current record device information database in ODBC. This function is extremely efficient when the subsequent getConfig is initially invoked. First of all, this function checks if the IP address is identical in ODBC. If the IP addresses are not identical, the record with the correct IP address is obtained from the database. Then the other fields are copied and the record is updated.</td>

<td>getConfig</td><td>This function gets a mapping table from ODBC for device information in a given format. The function returns true if there is data returned, false if there is no more data.</td>

<td>saveStatus</td><td>This function saves status information to ODBC. The function returns true when the save is successful, or false otherwise.</td>

Table 2 illustrates the functions of DeviceFactory 76.

TABLE 2

<td>createDevice</td><td>This function creates the device from the specification in the Device Factory (device object class). The function returns a pointer to the created device if the creation succeeds, or 0 otherwise.</td>

Table 3 illustrates the functions of DataTransfer 74.

TABLE 3

<td>startSend</td><td>This function triggers the Date Transfer to prepare for sending the data specified in the InfoType. The function takes over the EerrorCode.</td>

<td>dataSend</td><td>This function in the Date Transfer sends the received data to the appropriate destination after convenient formatting, encryption and encoding. The function returns the EerrorCode.</td>

<td>endSend</td><td>This function in the Data Transfer ends the sending of data. The function returns the EerrorCode.</td>

Table 4 illustrates the functions of Device 82.

TABLE 4

<td>getStatus</td><td>This function obtains information about the status from a device. The function returns true when the state is returned, false when the state could not be obtained. This function reinitializes the variable that preserves the error state before the return.</td>

<td>checkErrorStatus</td><td>This function triggers the device to check the error status that needs to be saved internally.</td>

ES 2 279 062 T3

Table 5 illustrates the functions of ODBC-2 84.

TABLE 5

<td>getManuflnfo</td><td>This function gets the name of the manufacturer, its vendor object identifier (OID), the OID in which the model information is stored, and the OID in which the unique identifier (ID) can be obtained. This function returns true when the data is returned, false when there is no more data available and all strings are set to null strings.</td>

<td>getSupportedModel</td><td>This function gets the Manufacturer (Manufacture) and the supported model. There may be more than one example from the same manufacturer, but the model is unique to the given manufacturer. This function returns true when the data is returned, false when there is no more data available and all strings are set to null strings.</td>

<td>getManufStatusInfo</td><td>This function gets the infoType and the OID associated with the infoType for the given Manufacturer. The obtained pair of infoType and OID is supported by all devices of the given manufacturer. This function returns true when the data is returned, false when there is no more data available and all strings are set to null strings.</td>

<td>getModelStatusInfo</td><td>This function gets the infoType and the OID associated with the infoType for the given Manufacturer and Model. This function returns true when the data is retrieved, false when there is no more data available and all strings are set to null strings.</td>

Table 6 illustrates the functions of SNMP 80.

TABLE 6

<td>setAgent</td><td>This function sets the contact IP address of the device.</td>

<td>getManufacturer</td><td>This function extracts for reading the manufacturer in the IP address. If the manufacturer is obtained, the function returns true. If the error is detected in the procedure, the function returns false.</td>

<td>getModel</td><td>This function extracts the device model for reading. If the model is obtained, including the null string, the function returns to true. If the error is detected in the procedure, the function returns false.</td>

<td>getUniqueld</td><td>This function returns the unique ID of the device. If the unique ID is obtained, including the null string, the function returns true. If the error is detected in the procedure, the function returns false.</td>

VendorModel 78 is responsible for obtaining information about the manufacturer and model of the monitored device. This software object obtains the manufacturer, model, and unique identifier of the monitored device. The CVendorModel class in VendorModel 78 uses information from the database to determine the manufacturers and models supported by the system. The class also uses information from the database necessary to obtain the model and unique identifier from the monitored device. Table 7 below shows the public and private functions of CVendorModel.

ES 2 279 062 T3

TABLE 7

<td></td><td>Function name</td><td>Description</td>

<td>Public</td><td>CVendorModel ()</td><td>Builder</td>

<td></td><td>~ CVendorModel ()</td><td>Destroyer</td>

<td></td><td>bool setAgent (std :: string &amp; in_slP)</td><td>Creates an SNMP session for the monitored device and obtains the manufacturer, model, and unique identifier of the device</td>

<td></td><td>bool getManufacturer (std :: string &amp; out sManufacturer)</td><td>Returns the device manufacturer</td>

<td></td><td>bool getModel (std :: string &amp; out sModel)</td><td>Returns the device model</td>

<td></td><td>bool getUnÍquelD (std :: string &amp; out_slD)</td><td>Returns the unique identifier of the device</td>

<td>Private</td><td>void setVectorAndMapAttrlbutes ()</td><td>Constructs a vector that contains information necessary to determine the manufacturer, model and unique identifier of the device and a correspondence table that contains information about manufacturers and models supported by the system</td>

<td></td><td>void obtainManufacturerQ</td><td>Obtains manufacturer information from the device</td>

<td></td><td>void obtainModel ()</td><td>Get model information from the device</td>

<td></td><td>void obtainUniquelDO</td><td>Get information about the unique identifier from the device</td>

<td></td><td>void convertToAIIUpper (std :: string &amp; inOut sString)</td><td>Converts the input string to all uppercase</td>

<td></td><td>std :: string Hexconvert (std;: string &amp; ¡N sStr¡ng)</td><td>Converts the input string to a hexadecimal string</td>

Table 8 below shows the attributes of the CVendorModel class that are used in the previous functions.

TABLE 8

<td>Guy</td><td>Attribute name</td><td>Description</td>

<td>CSNMP</td><td>m_SNMP</td><td>This attribute element is used to implement an SNMP session for monitored devices.</td>

<td>std :: vector &lt;Manufactur</td><td>m ManufacturerAndMo</td><td>This attribute element is a vector</td>

ES 2 279 062 T3

<td>erAndModellnfo&gt;</td><td>delInfoVector</td><td>A containing information about the object identifiers used to identify the manufacturer, model, and unique identifier of the monitored devices.</td>

<td>std :: map &lt;std :: str¡ng, std:: vector &lt;std:: str¡ng »</td><td>m_ManufacturerModel Map</td><td>This attribute element is a mapping table that lists all the models of a given manufacturer in the vector that the system supports.</td>

<td>std :: string</td><td>m_sManufacturer</td><td>This attribute element represents the Manufacturer of the monitored device.</td>

<td>std :: string</td><td>m_sModeI</td><td>This attribute element represents the Model of the monitored device.</td>

<td>std :: string</td><td>m_sUniquelD</td><td>This attribute element represents the unique identifier of the monitored device.</td>

<td>bool</td><td>m_bReturn</td><td>This attribute is set to true s) SNMP session succeeds in setAgentQ function; or, otherwise, false.</td>

<td>std :: str¡ng</td><td>m_sCurrentModelOID</td><td>This attribute element represents the object identifier used to find information about the model of the monitored device.</td>

<td>std :: string</td><td>m_sCurrentUniqueOID</td><td>This attribute element represents the object identifier used to find information about the unique ID such as a serial number of the monitored device.</td>

ManufacturerAndModelInfo in m_ManufacturerAndModelInfoVector has the following structure:

struct ManufacturerAndModelInfo {std :: string m_sManufacturer; std :: string m_sEnterpriseOID; std :: string m_sModelOID; std :: string m_sUniqueOID;

};

m_sManufacturer is the name of the manufacturer. m_sEnterpriseOID is the identifier of the company object associated with the manufacturer. The identifier of the company object is unique to a manufacturer. m_sModelOID is the object identifier that can be used to find the model name of the device. m_sUniqueOID is the object identifier that can be used to find the unique identifier of the device. The unique identifier can be the serial number of the device's MAC address.

DeviceFactory 76 is responsible for creating a device object that represents the monitored device. DeviceFactory 76 makes sure that the device object knows what state information it needs to get. CDeviceFactory is the only class in the DeviceFactory 76 package. Table 9 below shows the public and private functions of CDeviceFactory.

ES 2 279 062 T3

TABLE 9

<td></td><td>Function name</td><td>Description</td>

<td>Public</td><td>CDeviceFactory ()</td><td>Builder</td>

<td></td><td>~ CDeviceFactory ()</td><td>Destroyer</td>

<td></td><td>Virtual CDevice * createDevice (std :: string &amp; in_slP, CSNMP &amp; in_SNMP, std :: string &amp; in_sManufacturer, std :: string &amp; in_sModel, std :: string &amp; in_sUniquelD)</td><td>This function creates a device object that represents the monitored device and passes it to a vector that contains information about what status information to obtain.</td>

<td>Private</td><td>void setGenericDeviceVector ()</td><td>This function adjusts a vector to contain information used to obtain status information obtainable from all monitored devices.</td>

<td></td><td>void setManufacturerVectorMap ()</td><td>This function sets a mapping table to contain information used to obtain status information that is obtainable from all monitored devices from specific manufacturers.</td>

Table 10 that follows shows the attributes of the CDeviceFactory class that are used in the previous functions.

TABLE 10

<td>Guy</td><td>Attribute name</td><td>Description</td>

<td>CSupportODBC</td><td>m_SupportODBC</td><td>This attribute element represents an object used to access information in the database that is necessary to obtain information about the status of monitored devices.</td>

<td>std :: vector &lt;std :: pair &lt;infoTy pe, std :: string&gt;&gt;</td><td>m_GenericDeviceVector</td><td>This attribute element contains information used to obtain status information for monitored devices of all manufacturers and models.</td>

<td>std :: map &lt;std :: string, std: .vector &lt;std :: pair &lt;infoTy pe, std :: string&gt;&gt;&gt;</td><td>m_ManufacturerVectorMap</td><td>This attribute element contains information used to obtain status information for monitored devices of a given manufacturer.</td>

infoType is a number used in m_GenericDeviceVector and m_ManufacturerVectorMap used to represent a specific type of status information. For example, 503 represents a Paperless condition of the monitored device and 601 represents the lifetime count of the pages of the monitored device.

ES 2 279 062 T3

Device 82 represents a monitored device. It accesses information about the status of the monitored device. Status information includes information such as error status, page count, toner cartridge level, and alert notices. CDevice is the only class in the Device 82 package. Table 11 below shows the public functions of CDevice.

TABLE 11

<td></td><td>Function name</td><td>Description</td>

<td>Public</td><td>CDevice (std :: string &amp; ¡n_slPaddress, CSNMP &amp; in_SNMP, std :: str¡ng &amp; in_sManufacturer, std :: string &amp; in_sModel, std :: string &amp; in s uniquelD)</td><td>Builder</td>

<td></td><td>~ CDevice ()</td><td>Destroyer</td>

<td></td><td>bool getStatus (std :: map &lt;infoType, std :: string&gt; &amp; out_Statuslnformation)</td><td>This function gets the information about the status of the monitored device</td>

<td></td><td>bool checkErrorStatus ()</td><td>This function extracts for reading the error status of the monitored device</td>

<td></td><td>Bool setNumOIDVector (std :: vector &lt;std :: pair &lt;¡nfoType, std :: string&gt;&gt; &amp; in_Vector)</td><td>This function sets the vector that will be used to obtain the status information from the monitored device via SNMP.</td>

Table 12 that follows shows the attributes of the CDevice class that are used in the previous functions.

TABLE 12

<td>Guy</td><td>Attribute name</td><td>Description</td>

<td>std :: string</td><td>m_slP Address</td><td>This attribute element is the IP address of the monitored device.</td>

<td>CSNMP &amp;</td><td>m_SNMP</td><td>This attribute element is used to implement an SNMP session for monitored devices.</td>

<td>std :: string</td><td>m_sManufacturer</td><td>This attribute element is the manufacturer of the monitored device.</td>

<td>std :: string</td><td>m_s Model</td><td>This attribute element is the model of the monitored device.</td>

<td>std: .string</td><td>m_slln¡quelD</td><td>This attribute element is the unique ID for the monitored device.</td>

<td>char</td><td>m_cError</td><td>This attribute element is used to preserve the bad bits that represent the error status of the monitored device</td>

<td>std:: vector &lt;std:: pair &lt;infoTy pe, std :: string&gt;&gt;</td><td>m_NumOIDVector</td><td>This vector stores information that will be used to obtain the information about the status from the monitored device through SNMP.</td>

ES 2 279 062 T3

Figure 6 illustrates an exemplary sequence diagram at the time the system is initialized to obtain information about the object identifiers used to identify the manufacturer, model, and unique identifier and to obtain information about the manufacturers and models supported by the system. system. VendorModel 86 interacts with ODBC2 88 to obtain this information. ODBC2 88 provides an interface to the database to obtain information from the database requested by VendorModel 86. VendorModel 86 invokes the getManufInfo () 90 function of ODBC2 88 to obtain the object identifiers used to identify the manufacturer, model, and unique identifier of the devices monitored from the database. This information is stored in the m_ManufacturerAndModelInfoVector vector described in Table 8 above. getManufInfo () 90 is invoked a multitude of times until all object identifiers for all manufacturers supported by the system are read in from the database. VendorModel 86 then invokes the ODBC2 function getSupportedModel () 92 88 to obtain from the database the manufacturer and model supported by the system. This information is stored in the m_ ManufacturerModelMap mapping table described in Table 8 above. getSupportedModel () is invoked a multitude of times until all the models supported by the system are read from the database. To delete, modify or add the manufacturers and models supported by the system, the only change necessary is in the database that stores information about the manufacturers and models supported. When the manufacturers and models supported by the system change, no changes are required to the system. The information is entered by reading from the database during initialization.

Figure 7 illustrates an exemplary sequence diagram for creating device objects to represent monitored devices during initialization. Initially, system 8 (Fig. 1) attempts to establish communication with device 2. If system 8 cannot be configured to interface with device 2, configuration information such as manufacturer, model, and a number are obtained from device 2. Unique identifier. In the procedure for determining the configuration information, a determination is made in order to find out whether the device 2 is supported by the system 8 using information from the system support database (SSD 10). A device object is created using information from the SSD 10, thus establishing a communication protocol between the system 8 and the device 2 - regardless of whether or not the device is supported by the system 8 -. Subsequently, the configuration information for device 2 is updated in the System Configuration Database (SCD 6). SendlnterfaceManager 94 invokes getConfig () 102 from ODBC 96. ODBC 96 provides an interface to the database to obtain configuration information for monitored devices. The configuration information includes the manufacturer's name, model name and IP address of the monitored device, the name, telephone number, and email address of the contact person who is responsible for the monitored device. The database contains the configuration information for all the devices to be monitored. However, not all devices in the database may be supported by the system, as specified in the database associated with ODBC2 84 in Figure 5.

SendlnterfaceManager 94 invokes setAgent () 104, creating an SNMP session with the monitored device to obtain the manufacturer, model, and unique identifier of the device. More details of this feature are provided in Figure 8. SendlnterfaceManager 94 invokes getManufacturer () 106, getModel () 108 and getUniquelD () 110 from VendorModel 98 to extract for reading the manufacturer name, model name and unique identifier of the monitored device. SendlnterfaceManager 94 invokes createDevice () 112 from DeviceFactory 100 to create a device object for the monitored device. The device object will be used by SendInterfaceManager 94 to obtain information about the status of the monitored device. SendlnterfaceManager 94 invokes ODBC 96 updateConfig () to update the configuration information in the database.

All stages in the sequence are repeated until all monitored devices are obtained in the database. For each of the monitored devices a device object will be created. SendlnterfaceManager 94 will maintain each of the device objects.

Figure 8 shows the sequence diagram for executing the setAgent () 122 of VendorModel 118. SendlnterfaceManager 116 invokes setAgent () 122 of VendorModel 118. VendorModel 118 invokes setAgent () 124 of SNMP 120. This function establishes an SNMP session between the system and the monitored device. VendorModel 118 invokes its own function obtainManufacturer () 126 to obtain the name of the manufacturer of the monitored device. In function obtainManufacturer () 126, VendorModel 118 invokes getNextStringValueForOID () 128 from sNmp 120 to obtain from the monitored device the identifier of the business object via SNMP. The identifier of the business object is used to identify the manufacturer of the monitored device. VendorModel 118 invokes its own function obtainModel () 130 to obtain the model name of the monitored device. In the obtainModel () 130 function, VendorModel 118 invokes getNextStringValueForOID () 132 from SNMP 120 to obtain the model name of the device monitored via SNMP. VendorModel 118 invokes its own function obtainUniqueID () 134 to obtain the unique identifier of the monitored device. In the obtainUniqueIDO function 134, VendorModel 118 invokes getNextStringValueForOID () 136 from SNMP 120 to obtain the unique identifier of the monitored device via SNMP.

Figure 9 is an exemplary flow diagram for the VendorModel function setAgent (). In step 140, the variables representing the manufacturer's name, the model name, and the unique identifier are set to an empty string. These variables are m_sManufacturer, m_sModel and m_sUniqueID as exemplified in Table 8. In step 142, the identifier of the company object of the monitored device is obtained through SNMP. In step 144, the identifier of the business object obtained from the monitored device is compared with those supported by the system. The identifier of the company object and its corresponding manufacturer supported by the system are stored

ES 2 279 062 T3 in the m_ManufacturerAndModelInfoVector vector, as described in Table 8. The vector is scanned to determine if the company object identifier of the monitored device is found. If the identifier of the business object cannot be found in the vector, then step 156 will be processed next. If the identifier of the company object is found in the vector, then the manufacturer of the monitored device is supported by the system and step 146 is processed next. In step 146, the variable for the name of the manufacturer m_sManufacturer is set to the name of the manufacturer corresponding to the identifier of the company object in the vector. In step 148, the variables m_sCurrentModelOID and m_sCurrentUniqueOID for the object identifier used to find the model name and the unique identifier of the monitored device are set to the object identifiers corresponding to the identifier of the business object in the vector. In step 150, the model name is obtained from the monitored device via SNMP using the object identifier m_sCurrentModelOID.

In step 152, the model name obtained from the monitored device is compared with those supported by the system. The manufacturer and model supported by the system are stored in the mapping table m_ManufacturerModelMap as described in Table 8. The mapping table is scanned to determine if the model is found in the mapping table. If the model cannot be found in the mapping table, then step 156 will be processed next. If the model can be found in the mapping table, then the model of the monitored device is supported by the system and step 156 is processed next. 154. In step 154, the variable for the model name m_sModel is set to the model name obtained from the monitored device. In step 156, the unique identifier is obtained from the monitored device via SNMP using the object identifier m_sCurrentUniqueOID. The variable for the unique identifier m_sUniqueID is then set to the unique identifier obtained from the monitored device.

The VendorModel setAgent () function allows the system to obtain the manufacturer name and model name of the monitored device via SNMP to determine if the device is supported by the system. It also allows the system to verify the manufacturer's name and the model name.

Figure 10 exemplifies a sequence diagram in which the system obtains information used to obtain the information on the status concerning the specific manufacturer and model of the monitored devices. DeviceFactory 160 interacts with ODBC2 162 to obtain this information. ODBC2 162 provides an interface to the database to obtain information from it requested by DeviceFactory 160. DeviceFactory 160 invokes the ODBC2 162 function getManufStatusInfo () 164 to obtain information necessary to obtain the status information from monitored devices for a specific manufacturer via SNMP. The information includes a number (infoType) that represents some type of status information and an object identifier used to obtain the status information via SNMP. getManufStatusInfo () 166 is invoked a multitude of times until the information needed to get all the status information for a specific manufacturer is read in from the database. DeviceFactory 160 then invokes the ODBC2 162 function getModelStatusInfo () 168 to obtain information necessary to obtain status information from monitored devices for a specific model via SNMP. The information includes a number (infoType) that represents some type of status information and an object identifier used to obtain the status information via SNMP. getModelStatusInfo () 170 is invoked a multitude of times until the information necessary to obtain all the information about the state for a specific model is read in from the database. This sequence is invoked within the DeviceFactory createDevice () function when a device object is created for the monitored device. This information will be added to the device object as described in Figure 11.

Using the database to store information used to obtain the status information regarding the manufacturer and the status information regarding the model, status information to be obtained from the database can be easily modified, deleted or added to the database. monitored devices without any changes to the system.

Figure 11 shows the flowchart for the DeviceFactory createDevice () function. At step 174, a device object is created to represent the monitored devices. In step 176, a vector containing information necessary to obtain status information from devices of all manufacturers is assigned to a local vector. This vector corresponds to m_GenericDeviceVector described in Table 10. At step 178, the manufacturer name of the monitored device is checked to see if it is supported by the system (if not supported by the system, the manufacturer name is an empty string). If the manufacturer's name is not supported, then step 186 will be processed next. If the manufacturer's name is supported, then step 180 will be processed next.

In step 180, information necessary to obtain status information from the monitored device of a specific manufacturer is obtained from a mapping table, and added to the local vector. The mapping table corresponds to the m_ManufacturerVectorMap described in Table 10. In step 182, the model name of the monitored device is checked to see if it is supported by the system (if not supported by the system, the model name is an empty string). If the model name is not supported, then step 186 will be processed next. If the model name is supported, then step 184 will be processed next.

ES 2 279 062 T3

In step 184, it is obtained from a database with the information necessary to obtain information about the status from the monitored device of a specific manufacturer, and it is added to the local vector. In step 186, the local vector containing the information necessary to obtain all the information about the state of the monitored device is set in the device object. The device object will have information about what state information to extract for reading from the monitored device.

DeviceFactory creates and initializes all device objects so that it knows what state information to get.

Figure 12 shows the sequence diagram for executing the monitorStatus () function. The procedure sends the information about the status of the monitored devices to a desired location. SendlnterfaceManager 190 invokes startSend () 198 of DataTransfer 196 to prepare the system to send the information about the status of the monitored devices via e-mail (SMTP protocol). SendlnterfaceManager 190 invokes getStatus () 200 from Device 194 to obtain the information about the status of the monitored device. Device 194 corresponds to the monitored device and knows what status information to obtain. SendInterfaceManager 190 invokes saveStatus () 202 from ODBC 192 to store information about the status of the monitored device in the database. SendlnterfaceManager 190 invokes dataSend () 204 from DataTransfer 196 to send the information about the status of the monitored device via e-mail (SMTP protocol). The invocation steps of getStatus () 200, saveStatus () 202, and dataSend () 204 are repeated for each monitored device. There is a device object for each monitored device. SendlnterfaceManager 190 invokes endSend () 206 of DataTransfer 196 to complete sending the status information via email.

Figure 13 shows the sequence diagram for executing the function getStatus () 214 of Device 210. SendlnterfaceManager 208 invokes getStatus () 214 of Device 210 to obtain the information about the status of the monitored device. Device 210 represents a monitored device of a specific manufacturer and model. Status information will be obtained from monitored devices via SNMP. If the monitored device is not supported by the system, then the status information obtained from the monitored device is then the status information obtainable for all monitored devices (system-wide status information) such as error status. If the manufacturer of the monitored device is supported by the system but not the model, the status information obtained from the monitored device is then the status information for the entire system and the status information obtainable for all monitored devices in the system. manufacturer specific (manufacturer specific status information). If the manufacturer and model of the monitored device are supported by the system, the status information obtained from the monitored device is then the status information of the entire system, the manufacturer-specific status information, and the information about the status of the monitored device. Obtainable status for all monitored devices of the specific model (model-specific status information). Device 210 contains a vector so it knows what information it needs to get. Device 210 invokes getNextStringValueForOID () from SNMP 212 so that the system can get the status information from the monitored device through SNMP. getNextStringValueForOID () 218 ​​is called a multitude of times to get all the information about the state from the monitored device.

Figure 14 shows the tables in a database that contains information about the manufacturers and models supported by the system. The table also includes information about what information to obtain for each manufacturer and model. Manufacturer 230 is the table that contains information about the manufacturers supported by the system. Manufacturer 230 also contains the following information: company object identifier for the manufacturer, object identifier used to find the model name of the monitored device, and object identifier used to find the unique identifier of the monitored device. SupportedModelByManufacturer 220 is the table that contains the models with their corresponding manufacturer that are supported by the system. To add or remove manufacturers and models supported by the system, only the Manufacturer 230 and SupportedModelByManufacturer 220 tables need to be modified. No modification is required to the system code. The system will read the information in these tables from the database.

ComManufStatus 226 is the table that contains information about what information will be obtained from the monitored device based on its manufacturer name. The table contains the name of the manufacturer and a number that represents the type of information. ModelStatus 222 is the table that contains information about what information will be obtained from the monitored device based on its model name. The table contains the manufacturer's name, the model name, and a number that represents the type of information. To add or remove information to be obtained from the monitored device, only the ComManufStatus 226 and ModelStatus 222 tables need to be modified. No modifications need to be made to the system code. The system will read the information in these tables from the database.

EnumOID 224 is the table that contains information about the object identifier used to find the information corresponding to the number. The object identifier will be used by the system to find a specific type of information coming from the monitored device through SNMP. EnumCorrespondence 228 is the table that contains a description of the numbers used to represent a type of information. This table is not used by the system but will provide the user of the system with information about what the numbers represent.

ES 2 279 062 T3

Figure 15 shows an example of the contents of the database tables as described in Figure

14. The database used to store information about the manufacturers and models supported by the system is Microsoft Access.

Figure 16 shows the class diagram for the ODBC2 package. The CSupportODBC 232 class is the interface for this package to access information in the database. The CManufacturerData 240 class accesses information from the database necessary to obtain the manufacturer, model, and unique ID of the monitored device. The CSupportedModelData class 234 accesses information from the database about the manufacturer and model of the monitored device supported by the system. The CComManufStatusData class 236 accesses information from the database necessary to obtain information about the manufacturer status associated with the monitored device. The CModelStatusData class 238 accesses information from the database necessary to obtain information about the status of the model associated with the monitored device. The CManufacturerDatabase class 242 provides an interface to the table in the database that contains the information about the manufacturer. The CSupportedModelDatabase 244 class provides an interface to the table in the database that contains information about supported models. The CComManufStatusDatabase class 246 provides an interface to the table in the database that contains the information about the manufacturer's status. The CModelStatusDatabase 250 class provides an interface to the table in the database that contains the information about the state of the model. The CInfoTypeOIDDatabase class 248 provides an interface to the table in the database that contains the correspondence between the infoType enumeration and the object identifier.

CManufacturerDatabase 242, CSupportedModelDatabase 244, CComManufStatusDatabase 246, CModelStatus Database 250, and ClnfoTypeOIDDatabase 248 are all classes derived from CRecordset 252 of the Microsoft Foundation Class (MFC) class library.

The preceding description of the preferred embodiment of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed and, in light of the above teachings, many modifications or variations are possible. For example, one or more of the concepts described or shown in this document can be applied to the system and / or procedure disclosed in the related document US2002 / 52292, entitled "Method and System of Remote Support of Device Using Email". Furthermore, any concept or feature described in US2002 / 152292 can be applied to the systems or procedures disclosed in this document. The embodiments have been chosen and described to best explain the principles of the invention and its practical applications accordingly allow others skilled in the art to utilize the invention and various embodiments and with various modifications as appropriate for use. particular contemplated. The scope of the present invention is intended to be defined only by the claims appended hereto.