US20060107088A1 - Apparatus for managing a device, program for managing a device, storage medium on which a program for managing a device is stored, and method of managing a device - Google Patents

Apparatus for managing a device, program for managing a device, storage medium on which a program for managing a device is stored, and method of managing a device Download PDF

Info

Publication number
US20060107088A1
US20060107088A1 US11269769 US26976905A US2006107088A1 US 20060107088 A1 US20060107088 A1 US 20060107088A1 US 11269769 US11269769 US 11269769 US 26976905 A US26976905 A US 26976905A US 2006107088 A1 US2006107088 A1 US 2006107088A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
device
service operation
request
failure
step
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11269769
Inventor
Kojiro Katayama
Makoto Kawashima
Junichi Hirose
Kazushi Omori
Hiroyuki Hara
Shinichi Nakamura
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance or administration or management of packet switching networks
    • H04L41/06Arrangements for maintenance or administration or management of packet switching networks involving management of faults or events or alarms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing packet switching networks
    • H04L43/06Report generation
    • H04L43/065Report generation for device related reporting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing packet switching networks
    • H04L43/08Monitoring based on specific metrics
    • H04L43/0805Availability
    • H04L43/0817Availability functioning

Abstract

A remote site managing system manages, in a unified fashion, computers and peripheral devices installed at a customer site. The remote site managing system automatically receives information indicating a failure which has occurred or indicating a high possibility that a failure will occur in some of PC/servers or peripheral devices installed in a customer's office and provides maintenance services without causing a customer to be concerned about anything. Furthermore, transmission of a request to a maintenance service company and reception of a service operation report from the service company are performed by the remote site managing system in an unified fashion.

Description

    RELATED APPLICATION
  • This application is a divisional of application Ser. No. 09/985,225, filed Nov. 2, 2001, the entire disclosure for which is hereby incorporated by reference.
  • BACKGROUND OF THE INVENTION
  • 1. Field of the Invention
  • The present invention relates to a remote site managing system for remotely and comprehensively monitoring states of PC/server devices such as a general-purpose personal computer (PC) or a server computer connected via a computer network or the like and also states of peripheral devices serving as input/output devices such as a printer, a copying machine, and a scanner.
  • 2. Description of the Related Art
  • A system is known which is installed in an office to acquire information about an operation of a device installed in the office and also error information, log information, etc., thereof, to monitor and manage the device. It is also known to transmit, via a network, such information acquired in an office to a center server installed outside the office in order to monitor and manage the information thereby.
  • However, the known monitoring/managing system has the capability of monitoring or managing either only PC/server devices, that is, general-purpose computers, or only peripheral devices such as a printer or a copying machine.
  • This is because there is a large difference between the management procedure for general-purpose computers and that for peripheral devices. More specifically, to manage general-purpose computers, it is required that a program be written so as to provide a desired function depending upon a computer environment such as an operation system and the program be executed on a computer which is also managed by the managing system. In contrast, in the case of peripheral devices, it is practically impossible to add or modify a function.
  • Besides, in the case of peripheral devices, there are no standards for data formats and communication protocols for use by a monitoring/managing system in communicating with a peripheral device. Therefore, it is required to develop a management procedure for each peripheral device. Thus, each peripheral device is separately connected to a managing site system and separately managed.
  • As described above, the conventional management system for managing peripheral devices and that for managing PC/servers cannot be integrated into a single system, and they are used absolutely separately.
  • It is becoming increasingly popular to use both types of devices, that is, PC/servers and peripheral devices in an office, and thus there is a need for a technique for integrally monitoring and managing all those devices and performing maintenance service upon them.
  • However, to monitor and manage, using the conventional technique, both a PC/server and a peripheral device installed in an office, it is required for a service company (managing site) to install both systems for separately monitoring and managing the respective types of devices, wherein it is required to acquire information about the respective types of devices via separate communication lines. Therefore, the maintenance company has to perform a complicated management process, and high operating and running costs are needed.
  • SUMMARY OF THE INVENTION
  • In view of the above, it is an object of the present invention to provide a remote site managing system in which PC/servers and peripheral devices installed in an office are managed in a unified fashion at a managing site.
  • It is another object of the present invention to provide a remote site managing system in which a managing device automatically receives information indicating a failure which has occurred or indicating a high possibility that a failure will occur in one or more PC/servers or peripheral devices installed in an office, and a maintenance service is provided without troubling the customer, wherein transmission of a request to a maintenance service company and reception of a service operation report from the service company are performed in a unified fashion.
  • It is still another object of the present invention to provide a remote site managing system in which a device operation report indicating the status of a device installed in an office is generated on the basis of counter information and history of failures and provided to a customer.
  • According to an aspect of the present invention, a device is managed via a network in such a manner that when data indicating an occurrence of a failure in a device is received, data indicating a request for a service operation is generated. A company to perform a service operation upon the device is selected from a plurality of companies, and the data indicating the request for the service operation is sent to the selected company.
  • In this aspect, in response to the data indicating the request for the service operation, data indicating a service operation report is preferably sent from the company.
  • Preferably, in the present aspect of the invention, an identifier is assigned to the request for the service operation when the data indicating the request for the service operation is generated, and the status of the request for the service operation is managed on the basis of the identifier.
  • In the present aspect of the invention, the data indicating the request for the service operation may be transmitted together with the identifier, and the data indicating the service operation report may be received together with the identifier. The status of the request for the service operation corresponding to the received identifier may be changed in accordance with the received data indicating the service operation report.
  • In the present aspect of the invention, the data indicating the request for the service operation is preferably transmitted by means of an electronic mail.
  • Preferably, in the present aspect of the invention, device information identifying a device having a failure is received, and a company is selected on the basis of the received device information.
  • Preferably, in the present aspect of the invention, failure information identifying a failure is received, and the received failure information is described in the data indicating the request for the service operation.
  • Preferably, in the present aspect of the invention, data indicating a manner of dealing with the failure identified by the received failure information is described in the data indicating the request for the service operation.
  • Preferably, in the present aspect of the invention, when it is determined that a customer possessing the device should deal with the failure, customer information associated with the customer and a message indicating the manner of dealing with the detected failure are displayed on a display unit.
  • Preferably, in the present aspect of the invention, in the case where an outside company should deal with the failure, a company is selected for that purpose.
  • According to another aspect of the present invention, a device is managed via a network in such a manner that when data indicating an occurrence of a failure in a device is received, data indicating a request for a service operation is generated. The data indicating the request for the service operation is sent to a company assigned to perform a maintenance operation for the device. Count information associated with the device is acquired, and data indicating a device operation report associated with the device is generated in accordance with the acquired count information, wherein device information indicating a device which has encountered a failure a plurality of times is described in the data indicating the device operation report.
  • According to still another aspect of the present invention, a device is managed via a network in such a manner that when data indicating an occurrence of a failure in a device is received, data indicating a request for a service operation is generated, and the data indicating the request for the service operation is sent to a company assigned to perform a maintenance operation for the device. The status of the service operation request is managed when the data indicating the service operation request is generated, count information associated with the device is acquired, and data indicating a device operation report associated with the device is generated in accordance with the acquired count information. In accordance with the status of the service operation request, device information indicating a device having an unsolved failure which has been requested to be dealt with via the service operation request is described in the data indicating the device operation report.
  • According to still another aspect of the present invention, a device is managed via a network in such a manner that when data indicating an occurrence of a failure in a device is received, data indicating a request for a service operation is generated, and the data indicating the request for the service operation is sent to a company assigned to perform a maintenance operation for the device. Count information associated with the device is acquired, and data indicating a device operation report associated with the device is generated in accordance with the acquired count information. Device information indicating a device which has not encountered a failure is described in the data indicating the device operation report.
  • Further objects, features and advantages of the present invention will become apparent from the following description of the preferred embodiments with reference to the attached drawings.
  • BRIEF DESCRIPTION OF THE DRAWING
  • FIG. 1 is a block diagram illustrating a managing site and a managed site.
  • FIG. 2 is a block diagram illustrating software modules used in a remote site managing system according to an embodiment of the present invention.
  • FIG. 3 is a block diagram illustrating a configuration of a computer such as a personal computer or a server.
  • FIG. 4 is a block diagram illustrating a procedure of transmitting data between a user-site system and a center system.
  • FIG. 5 is flow chart illustrating a process which is performed by the device center in response to a receiving a message.
  • FIG. 6 is a flow chart illustrating a process performed in response to an occurrence of an event in the device monitoring server 203 a.
  • FIG. 7 is a flow chart of a process performed by the device monitoring server 203 a in response to receiving a message from the device center server 210.
  • FIG. 8 is a table illustrating an example of a format of a message transmitted between the device center server 210 and the device monitoring server 203 a.
  • FIG. 9 is a block diagram illustrating software modules used in a remote site managing system according to an embodiment of the present invention.
  • FIG. 10 is a diagram illustrating a process performed by a user-site system and a center system to download a setting value associated with a device.
  • FIG. 11 is a diagram illustrating a process performed between the user-site system and the center system to acquire information about a device, for example, to update count data.
  • FIG. 12 is diagram illustrating a process of uploading log data from the user-site system to the center system.
  • FIG. 13 is a flow chart of a process performed by the center server 110 in response to receiving an event.
  • FIG. 14 is a flow chart of a process performed by a device information processing module 901 in response to an event indicating completion of downloading.
  • FIG. 15 is a flow chart of a process performed by the device information processing module 901 in response to notification of acquisition of device information (counter value).
  • FIG. 16 is a flow chart of a process performed by the device information processing module 901 in response to a request for uploading log data.
  • FIG. 17 is a flow chart of a process performed by a user-site plug-in module 203 b in response to receiving a message or an event issued to the plug-in module.
  • FIG. 18 is a flow chart of a process performed by the user-site plug-in module 203 b in response to a message received from a center server 1101.
  • FIG. 19 is a flow chart of a process performed by a PC monitoring client module in response to receiving a message.
  • FIG. 20 is a flow chart of a process performed by an application system used in a managing site (center system).
  • FIG. 21 is a diagram illustrating a data structure of a failure event.
  • FIG. 22 illustrates a failure list displayed on a screen.
  • FIG. 23 is diagram illustrating a list of failures which have occurred in a particular device of a customer, wherein the list of failures is displayed on a display screen.
  • FIG. 24 illustrates a failure code master table.
  • FIG. 25 illustrates a device number (serial number) master table.
  • FIG. 26 illustrates a customer mater table.
  • FIG. 27 illustrates a manner of displaying, on a display screen, a method of dealing with a failure.
  • FIG. 28 illustrates a trouble ticket table.
  • FIG. 29 is a flow chart illustrating a process of generating and transmitting a request for a service operation.
  • FIG. 30 illustrates a template file of a service operation request/report.
  • FIG. 31 illustrates a service company master table.
  • FIG. 32 is a flow chart illustrating a process of generating and transmitting a service operation report.
  • FIG. 33 is a flow chart of a process performed by an application system used in a managing site (center system).
  • FIG. 34 illustrates a counter information table.
  • FIG. 35 illustrates a template file of a device operation report.
  • DESCRIPTION OF THE PREFERRED EMBODIMENTS First Embodiment of a Remote Site Managing System
  • A first embodiment of a remote site managing system according to the present invention is described below with reference to the accompanying drawings.
  • FIG. 1 is a block diagram illustrating the remote site managing system including a managing site (maintenance service company) and a managed site (office). At the managed site, there are provided general-purpose computers and peripheral devices. More specifically, the general-purpose computers include a PC 103 and a device monitoring server 203 a (information device for managing peripheral devices connected via a local network installed in the office), and the peripheral devices include a copying machine 101, a printer 105, and a printer 104 which are connected via a LAN (local area network).
  • Herein, the term “general-purpose computer” refers not only to a personal computer or a server computer but also a network device such as a gateway or a router which is necessary in a computer network. The term “peripheral device” refers to a device such as a copying machine, a printer, a scanner, a facsimile machine, and a multifunction device.
  • The PC 103 executes a PC monitoring client module, which will be described in detail later, to manage general-purpose computers connected via a local network installed in an office. The device monitoring server 203 a and the PC monitoring client module may be executed by physically separate computers or may be executed by a single computer.
  • Although not shown in FIG. 1, the present remote site managing system includes a data format conversion apparatus for converting data into a format which is suitable for being dealt with by the device monitoring server 203 a and into a format which is suitable for being dealt with by the PC monitoring client module.
  • At the managing site, there are provided a center server 110 for managing devices at the managed site in an unified fashion, an inventory database 109 for storing managing information, and a device center server 210 dedicated to managing the peripheral devices at the managed site, with these devices connected via a LAN. The present system further includes another computer, that is, a server/PC 111, connected via the LAN. The computer 111 is used to execute an application program to manage office devices in a unified fashion in accordance with management information.
  • At the managing site, although not shown in FIG. 1, there are also disposed a display for displaying information received from the managed site and also a data format conversion apparatus for converting data into a format suitable for being dealt with by the center server 110 and into a format suitable for being dealt with by the device center server 210, respectively.
  • In some cases, a service center (as is the case with an application system 205 shown in FIG. 2) are connected to a plurality of managing sites via an external network or a LAN so as to manage the plurality of managing sites in an unified fashion.
  • The managed site and the managing site are connected to each other via gateways 106 and 107. Alternatively, the connection between them may be achieved using a general-purpose router or a modem. In the case where the PC monitoring client module is executed on the PC 103, the PC 103 and the center server 109 may be connected to each other via a communication line, and the device monitoring server 203 a and the device center server 210 may be connected to each other via another separate communication line.
  • FIG. 3 is a block diagram illustrating a configuration of a computer serving as a personal computer or a server computer. As shown in FIG. 3, a computer 3000 includes a CPU 1, a RAM 2, a ROM 3, a system bus 4, a KBC 5, a CRTC 6, a MC 7, a LAN controller 8, a KB 9, a CRT 10, and an external memory 11.
  • The CPU 1 executes a communication control program stored in a program ROM in the ROM 3 to control the operation of transmitting specified data to the outside and also the operation of receiving data from the outside. The CPU 1 also controls the operations of respective devices connected to the system bus 4.
  • The RAM 2 serves as a main memory and a work area used by the CPU 1. The ROM 3 serves to store a font (in a font ROM), a program (in a program ROM), and data (in a data ROM). The keyboard controller (KBC) 5 controls the operation of inputting data via a keyboard 9 or a pointing device (not shown). The CRT controller (CRTC) 6 controls the operation of displaying data on the CRT display 10. The memory controller (MC) 7 controls accessing to the external memory 11. The external memory 11 such as a hard disk (HD) or a floppy disk (FD) is used to store a boot program, various applications, font data, a user file, and an edit file which will be described later. The LAN controller 8 is connected to a network so as to control communication with another device connected via the network.
  • FIG. 2 is a block diagram illustrating software modules in the present remote site managing system. A user-site system (managed site system) includes peripheral devices (such as a copying machine, a printer, a multifunction device, a scanner, or a facsimile machine) and PC/server devices (such as a general-purpose computer), wherein the peripheral devices are locally managed by a device monitoring server 203 a, and the PC/server devices are locally managed by a PC monitoring client module 203 d. The device monitoring server 203 a and the PC monitoring client module 203 d are generically referred to as a user-site management system 203. The device monitoring server 203 a includes database 203 a-1 for storing management information.
  • The center system (managing site system) includes a device center server 210 which communicates with the device monitoring server 203 a and also includes a center server 110 which communicates with the PC monitoring client module 203 d. The management information associated with the peripheral devices is stored in an inventory database 109. The management information managed by the center server 110 is also stored in the inventory database 109. The management information stored in the inventory database 109 is used by an application system 205. The inventory database 109 includes a database associated with peripheral devices and a database associated with general-purpose computers such as a PC or a server, wherein these databases are logically separated from each other. The databases may also be separated physically.
  • The device monitoring server 203 a and the device center server 210 are connected to each other via a user-site plug-in module 203 b and a server plug-in module, which serve to convert a data format or a procedure as required whereby the device monitoring server 203 a and the device center server 210 can communicate with each other even when the operating system is different between the user site and the center. Electrically, the connection is made via a router 204. The communication line is physically or logically shared for connection between the PC monitoring client module 203 d and the center server 110 and for connection between the user-site plug-in module and the server plug-in module.
  • In some cases, a line via which the device center server 210 and the device monitoring server 203 a are connected to each other is disposed separately from a line for connecting the PC monitoring client module 203 d and the center server to each other. In this case, the connection may be made using a communication line disposed separately from the line between the PC monitoring client module 203 d and the center server 110.
  • The center server 110 includes an event monitor 110 a. The event monitor 110 a monitors an event issued to the center server 110 and, if an event indicating a failure is detected, the event monitor 110 a displays the detected event on a monitor screen to inform a human manager of the event of the failure at the managed site. Such an event may be issued to the center server 110 by an event adapter 210 a, the PC monitoring client module 203 d, or the application system 205. Upon receiving the event, the center server 110 performs a predetermined process depending upon the content of the event. An example of such an event is a failure message.
  • The device center server 210 includes the event adapter module 210 a. The event adapter 210 a has the capability of retrieving, at scheduled intervals, information transmitted from the device monitoring server 203 a to the device center server 210. From the retrieved information, the event adapter 210 a detects information indicating a failure which has occurred in a peripheral device and converts the information into a format (formats of file and protocol) which can be dealt with by the center server 110. The information is transmitted, as an event indicating the occurrence of the failure, to the center server 110. Alternatively, instead of converting the information into the format which can be dealt with by the center server, the conversion may be performed by the center server 110. An event (failure event) indicating an occurrence of a failure includes information about the type of the failure, a device which has encountered the failure, and a time at which the failure occurred. By providing the event adapter module 210 a in the present system, device information indicating, for example, an occurrence of a paper jam or indicating the capability of a stapling function, acquired via management software which uses a protocol or a format assumed to be used only by peripheral devices, can be managed in an unified fashion together with information acquired via software which manages other types of systems or apparatuses (such as a general-purpose computer or a server).
  • Upon receiving the failure event, the event monitor 110 a adds the failure event to an event list and displays the information about the type of the failure, the device which has encountered the failure, and the time at which the failure occurred. The information may be displayed, for example, in the form of a list of events in which one event is described in one row in the order of occurrence time. Although in the example shown in FIG. 2, the event monitor 110 a is disposed in the center server 110, the event monitor 110 a may be disposed outside the center server 110. In this case, the event monitor 110 a is connected to the center server 110 via a network. This makes it possible for the device center server 210 or the application system 205 to comprehensively manage the peripheral devices and the PC/server devices.
  • Note that, regardless of where an event occurs, the event monitor 110 a can display an indication of the occurrence of a failure event to inform a human manager of the occurrence of the failure. That is, the event monitor 110 a displays a list of events on the monitor screen such that the list of events includes, in a time-sequential fashion, failure events issued by the PC monitoring client module 203 d to indicate occurrences of failures of general-purpose computers and also includes failure events issued by the device monitoring server 203 a via the event adapter 210 a of the device center server 210 to indicate occurrences of failures of peripheral devices.
  • An example of a data transmission procedure between the device center server 210 and the device monitoring server 203 a is described below with reference to FIG. 4, for the following three cases: (1) a setting value is downloaded from the device center server 210 to a device; (2) log data is uploaded from the device monitoring server 203 a to the device center server 210; and (3) a request for counter data is transmitted from the device center server 210 to the device monitoring server 203 a. Before describing the procedure, a data format is described briefly.
  • FIG. 8 illustrates an example of a format of a message transmitted between the device center server 210 and the device monitoring server 203 a. Each message includes a flag field, a data type field, a job ID field, a return value field, a data length field, and a data field. The flag field includes a set of bits indicating communication means a bit indicating whether the message is in a frame at the end of data.
  • The data type field is used to indicate whether the message is authentication request data (transmitted at the beginning of a session), setting value data to be downloaded, a device information request which will be described later, an event information message, or a log data request. For example, in the case of a failure event message, the data type field is described so as to indicate that the message is an event information message, and the specific content of the message is described in the data field.
  • The job ID indicates the type of a session. More specifically, the job ID indicates whether a session is used to set a parameter, acquire device information, or transmit an event. The data length field indicates the length of data described in the data field. When a setting value is downloaded or log data is transmitted in response to a request, the data is described in the data field. In the case where count information is uploaded, device information is described in the data field of a message returned in response to a device information request.
  • In the procedures described below, processes are performed while transmitting messages between the device center server 210 and the device monitoring server 203 a. Note that, in the following description, the term “event” is used to describe a message indicating an occurrence of an event.
  • Procedure of Downloading a Setting Value
  • FIG. 4 is a block diagram illustrating a procedure of transmitting data between the user-site system and the center system.
  • A setting value is downloaded as follows.
  • (1) In the application system 205, a setting value information file 401 is generated by inputting, for example via a manual operation, data specifying a device which is to be set, the IP address of the device, and a setting value such as a threshold value which defines a limit of a particular value such that if the value changes beyond the threshold, an alarm indicating an occurrence of an error in the device is generated to the user-site device server.
  • (2) The application system 205 establishes a session with the device center server 210 and transmits setting value data included in a setting value information file 401.
  • (3) Upon receiving the setting value data, the device center server 210 establishes a session with the device monitoring server 203 a and transfers the setting value data to the device monitoring server 203 a.
  • (4) Upon receiving the setting value data, the device monitoring server 203 a transmits the setting value to a device in accordance with a predetermined procedure depending upon the device.
  • (5) After completion of setting the device, the device monitoring server 203 a transmits a message to the device center server 210 to inform that the setting of the device has been completed.
  • (6) The device center server 210 transmits a setting completion message to the application system 205.
  • Thereafter, the application system 205 releases the session with the device center server 210, and the device center server 210 releases the session with the device monitoring server 203 a.
  • As described above, the device setting information is downloaded to the device 402 via direct communication between the device monitoring server 203 a and the device center server 210.
  • On the other hand, a message indicating an occurrence of a failure is transmitted as follows.
  • (7) When the PC monitoring client module 203 d detects a failure in some server or a PC, the PC monitoring client module 203 d issues a failure event directly to the center server 110.
  • (8) In the case where a failure of the device 402 is detected by the device monitoring server 203 a, the device monitoring server 203 a transmits a failure message to the device center server 210.
  • (9) Upon receiving the message indicating the occurrence of the failure in the device 402, the device center server 210 issues an event to inform the center server 110 of the occurrence of the failure. In the example shown in FIG. 4, the device center server 210 includes an event adapter 201 a shown in FIG. 2, and thus the failure event is issued by the event adapter 201 a.
  • (10) When the event monitor 110 a detects the failure event, the event monitor 110 a displays the failure information on an event console and updates the event list.
  • As described above, the event indicating the occurrence of the failure is passed through the center server 110 regardless of whether the failure occurs in some peripheral or some general computer at the managed site, and thus a human manager can monitor the information associated with all peripheral devices and general-purpose computers at the managed site simply by watching the event console of the center server. The information displayed on the event console may be printed or displayed on a portable terminal carried by a service person. The printed information may be sent by mail to a user. In response to the information displayed on the portable terminal of the service person, the service person may go to the user site. Thus, the information about the peripheral devices and the PC/servers, managed in the unified fashion, can be used for various purposes.
  • In the above description, a failure of a peripheral device is displayed on the event console 110 b via the event monitor 110 a shown in FIG. 4. However, in the present invention, all failures of peripheral devices are not displayed on the event console 110 b. That is, when a failure occurs in a peripheral device, it is determined whether or not a failure event should be transmitted to the device center server 210 on the basis of the level of the failure.
  • For example, in the case of an error from which it is possible to recover simply by resetting a device or turning on/off the device, such as an open-door error in a copying machine, a message indicating the occurrence of the error is not transmitted from the device monitoring server 203 a to the device center server 210. On the other hand, when the center server receives a message indicating an error which can be easily corrected by a customer, such as a paper jam or a temperature increase which will not cause a significant failure, a service person is not sent to the customer.
  • If the database used to determine whether or not a message indicating a failure should be sent to the center server is stored in one of devices such as the monitoring database 203 a-1 or the device 402 disposed at the managed site, it is possible to determine, at the managed site, whether information should be transmitted from the managed site to the managing site.
  • On the other hand, the database used to determine whether or not failure information received by the center server 110 should be displayed on the event console 110 b or to determine whether or not failure information should be sent to a service person, may be stored in the application system 209, the inventory database 109, or the center server 110, disposed at the center server site.
  • As described above, because the present system has the capability of filtering information to be transmitted, the volume of communication traffic between the user site and the center site can be reduced. In addition, this arrangement allows a human manager at the center site to easily and surely detect a significant error.
  • Procedure of Uploading Count Information
  • Uploading of a count value, that is, acquisition of device information, is performed as follows. Herein, the count value refers to a value indicating the number of pages printed by a copying machine or a printer, or a mode counter value indicating the number of times that a device has been used in a particular mode. The fee for the maintenance is determined on the basis of the count value. By uploading the count value in response to a request issued by the center system, it becomes possible to acquire the count value or other device information from a remote site. The uploading of count information is initiated in response to a request issued by the application, and thus the center system (managing site) serves as an initiator.
  • (1) The application system 205 establishes a session and transmits a device information request to the device center server 210. The device information request includes information specifying a device at the user site.
  • (2) Upon receiving the device information request, the device center server 210 establishes a session with the device monitoring server 203 a and transmits the device information request to the device monitoring server 203 a.
  • (3) Upon receiving the device information request, the device monitoring server 203 a acquires device information from the specified device. The above process is performed in accordance with a predetermined procedure depending upon the device, wherein the information is specified for each device.
  • (4) If the device information has been acquired, the device monitoring server 203 a transmits a device information response including the acquired device information to the device center server 210.
  • (5) The device center server 210 transfers the device information response to the application system 205.
  • Thereafter, the application system 205 releases the session with the device center server 210, and the device center server 210 releases the session with the device monitoring server 203 a.
  • As described above, the device information can be acquired via direct communication between the device monitoring server 203 a and the device center server 210.
  • A failure event can be transmitted in a similar manner to the downloading of a setting value.
  • Procedure of Uploading Log Data
  • Uploading of log data is performed as follows. Log data refers to data indicating the history of alarms or retries which have generated or performed in a peripheral device. Even when an error is not detected, if alarms have been generated a greater number of times than a predetermined number, the device is regarded as being in an abnormal status, and the managing site is informed of the status. Therefore, in the uploading of log data, unlike the uploading of a counter value, the managed site system (user site system) is an initiator.
  • (1) The device monitoring server 203 d describes the log data associated with devices. If the data size of the log data becomes greater than a predetermined value, or if alarms are generated at a rate greater than a predetermined value, the device monitoring server 203 a uploads the log data.
  • (2) The device monitoring server 203 a establishes a session and transmits a log data processing request including log data to the device center server 210.
  • (3) Upon receiving the log data processing request, the device monitoring server 203 a establishes a session with the device center server 210 and transmits the log processing request to the device center server 210.
  • (4) Upon receiving the log data processing request, the device center server 210 establishes a session with the application system 205 and transmits the log data processing request to the application system 205 which is assigned to process the log data.
  • (5) Upon receiving the log data processing request, the application system 205 processes the log data received together with the log data processing request. After completion of processing the log data, the application system 205 transmits a log data processing response to the device center server 210.
  • (6) The device center server 210 transfers the log data processing response to the device monitoring server 203 a.
  • (7) The device monitoring server 203 a releases the session with the device center server 210 and performs post-processing. In the post-processing, if the log data processing response indicates that the processing of the log data has been successfully completed, the log data is deleted.
  • Thereafter, the device center server 210 releases the session with the application system 205.
  • As described above, log information can be uploaded via direct communication between the device monitoring server 203 a and the device center server 210.
  • A failure event can be transmitted in a similar manner to the downloading of a setting value.
  • Procedure Performed by the Device Center Server
  • The processes performed by the device center server 210 and the device monitoring server 203 a are briefly described below. FIG. 5 is a flow chart illustrating a process which is performed by the device center server when the device center server receives a message. The message is not necessarily from the device monitoring server but may be from the application system 205. The format of the message may be different from the format shown in FIG. 8. In any case, the issuer of the message can be identified or the process is performed differently depending upon the issuer of the message. In the present embodiment, it is assumed that the issuer of the message can be identified.
  • When a message is received, the process shown in FIG. 5 is started. First, the received message is analyzed (step S501) to determine which device has issued the message (step S502). The issuer may be indicated by adding its address to the message. Alternatively, the issuer may be determined on the basis of the content of the message. For example, if the message is a log data processing request, the issuer must be the device monitoring server. If the message is a request for downloading a setting value, the issuer must be the application system (represented as the back-end system in the flow chart).
  • In the case where the message has been issued by the device monitoring server 203 a, it is determined whether or not the message is a failure event (step S503). If the message is a failure event, the message is transferred to the center server 110 after being converted into a format which can be dealt with by the center server 110 (step S504). The center server 110 detects the type of the failure and the location and the time of the failure from the message and displays them (step S505). In the case where the message is not a failure event, the message is transferred to the application system which in turns performs a process in accordance with the message. Thereafter, the process waits for another message. Examples of processes transferred to the application system include a log data processing request and acquired device information.
  • In the case where the message has been issued by the application system, it is determined whether or not the message is a device information acquisition request (step S506). If yes, the device information acquisition request is transmitted to the device monitoring server 203 a and the process waits for another message.
  • If the message is not a device information acquisition request, it is determined whether the message is a request for downloading a setting value (step S508). If the message is a download request, the data requested to be downloaded is acquired (step S509), and the acquired data is transmitted to the device monitoring server 203 a (S510).
  • Procedure Performed by the Device Monitoring Server
  • FIG. 6 is a flow chart illustrating a process performed in response to an occurrence of an event in the device monitoring server 203 a.
  • If an event occurs, the event is analyzed (step S601). If the event is a warning, and if the number of warnings has reached a value greater than a predetermined threshold (S602), the log data which has been stored is acquired, and a message indicating a request for processing log data is created (step S603) and transmitted to the device center server 210. However, if the threshold value has not been reached, the warning is described in the log data.
  • If the event is not a warning, it is determined that an error has occurred, and a message indicating a failure event is generated (step S605). In step S604, the message is transmitted to the device center server 210.
  • FIG. 7 is a flow chart illustrating a process performed by the device monitoring server 203 a in response to receiving a message from the device center server 210.
  • First, it is determined whether or not the received message is a request for downloading a setting value (step S701). If the received message is a download request, setting is performed by the device monitoring server 203 a and the device in accordance with received setting data (step S702). Thereafter, the user-site plug-in module 203 b deletes the data (step S703) and transmits, to the device center server 210, a message indicating that the downloading has been completed (step S704). Note that the user-site plug-in module 203 b is required to logically connected to the device monitoring server 203 a, but it is not necessarily required to be physically connected.
  • In the case where the message it not a download request, it is determined whether or not the message is a device information acquisition request (step S706). If the message is a device information acquisition request, information is acquired from a specified device (step S707), and the acquired information is transmitted to the device center server (step S708).
  • The above-described procedure makes it possible to integrate the system for managing general-purpose computers and the system for managing peripheral devices into a single managing system thereby making it possible to manage failure events in the unified fashion. The present invention is not limited to a system in which managing information associated with peripheral devices is adapted to the software designed to manage PC/servers, but the present invention may also be applied to a system in which management information associated with PC/servers is adapted to the software for managing peripheral devices. For example, the event adapter module 210 a shown in FIG. 2 may be installed in the center server 110 and an event generated by a device server may be transmitted to the device center server 210.
  • As in the example shown in FIG. 2, the same line may be used in common via a router or the like for communication between the device monitoring server 203 a and the device center server 201 and for communication between the PC monitoring client module 203 d and the center server 110. This allows a reduction in the total number of communication lines. This is useful in particular when private lines are employed.
  • Second Embodiment of a Remote Site Managing System
  • Referring to the drawings, a second embodiment of a remote site managing system according to the present invention is described below. The second embodiment of the system differs from the first embodiment in the manner in which logical channels are formed between the managing site and the managed site. In the first embodiment, although a communication line is shared, the channel used for communication between the device monitoring server 203 a and the device center server 210 is logically independent of the channel for communication between the PC monitoring client module 203 d and the center server 110. When the device center server 210 receives a message indicating a failure event from the device monitoring server 203 a, the message indicating the failure event is transferred to the center server 110 so that failure events are managed by the event monitor in the unified fashion.
  • In contrast, in the present embodiment, there is neither the device center server 210 nor the channel for communication between the device center server 210 and the device monitoring server 203 a. Instead of the device center server, a device information processing module 901 is disposed in the center server 110 (they are disposed in a separate fashion in the example shown in FIG. 9) to process information associated with a peripheral device received by the center server 110. In this configuration, when a commercially available PC monitoring client module 203 d and center server 110 are employed, a message associated with a peripheral device is also transmitted via a channel established between them. This provides, in addition to the advantage that the line can be shared as in the first embodiment, another advantage that it is not required to establish an independent communication channel for transmitting information associated with a peripheral device, and it is not required to separately provide a device center server.
  • System Configuration
  • FIG. 9 is a block diagram illustrating software modules in the remote site managing system according to the present embodiment. The user site system (managed site system) includes peripheral devices (such as a printer, a copying machine, a scanner, a facsimile machine, a multifunction device, etc.) and PC/server devices (such as a general-purpose computer), the peripheral devices are managed by a device monitoring server 203 a, and the PC/server devices are managed by a PC monitoring client module 203 d, as in the first embodiment described above.
  • The center system (managing site system) includes a device information processing module 901 which communicates with the device monitoring server 203 a, and a center server 110 which communicates with the PC monitoring client module 203 d. Management information associated with the peripheral devices and that associated with PC/servers are stored in an inventory database 109. Although in FIG. 9 the inventory database 109 has a single form, the inventory database 109 includes, in practice, a database associated with peripheral devices and a database associated with purpose-purpose computers such as a PC or a server, wherein these databases are logically separated from each other. The databases may be separated physically as well. The information stored in the database 109 is used by the application system 205, the center server 110, and other devices, as in the first embodiment.
  • The managed site and the managing site are connected to each other via a communication line extending between routers 204 disposed at the respective sites. The PC monitoring client module 203 d and the center server 110 may be realized using a commercially available site management system. Any message is transmitted or received via a channel established between the PC monitoring client module 203 d and the center server 110 provided by the commercially available management system. Although in the example shown in FIG. 9, the device information processing module 901 (corresponding to the device center server 210 in the system shown in FIG. 2) is provided in a separate fashion, the device information processing module 901 may be incorporated in the center server 110.
  • The device monitoring server 203 a and the PC monitoring client module 203 d are connected to each other via a user-site plug-in module 203 b for converting a data format or a communication protocol as required. That is, the user-site plug-in module 203 b has the capability of converting information transmitted from the device monitoring server into a format (or protocol) which can be dealt with by the PC monitoring client module 203 a, and the user-site plug-in module 203 b also has the capability of performing an inverse conversion. Alternatively, the function of the use-site plug-in module 203 b may be incorporated into a plug-in module (corresponding to the server plug-in module shown in FIG. 2) provided, in the center site, for transferring data between the center server 110 and the device processing module 901.
  • As will be described in detail later, the user-site plug-in module 203 b transfers a message received from the device monitoring server 203 a to the PC monitoring client module 203 d to transmit it to a specified destination. The user-site plug-in module 203 b also periodically checks, by means of polling, the contents in a predetermined storage area assigned as an area in which a message is written by the PC monitoring client module 203 d. If there is a message to be transmitted to the device monitoring server 203 a, the user-site plug-in module 203 b transfers the message to the device monitoring server 203 a.
  • The center server 110 deals with the received message differently depending upon the content of the message. That is, if the content of the message is associated with a peripheral device, the center server 110 transfers the message to the device information processing module to process it. In the case where the received message is a message indicating an occurrence of an event, the center server 110 converts the event data into a format which can be dealt with by the event monitor 110 a to determine whether the event is associated with a peripheral device or a PC/server and the event is displayed in the form of an event list. In the case of an event associated with a peripheral device, the event is generated by the device information processing module 901.
  • As described above, by providing the plug-in module having the capability of converting data into formats suitable for being dealt with by the peripheral devices and the PC/servers, it becomes possible to transmit information associated with a peripheral device between the user site and the managing site, and the information can be managed using the functions of the commercially available PC/server management software. In the case of special device information which cannot be managed by the commercially available PC/server management software, the data indicating device information is converted, at the center site, from a format for use by the PC/server devices into a format for use by the peripheral device, and the resultant data is dealt with by the device information processing module. When it is desired to manage device information in a special manner, the purpose can be achieved by modifying only the device information processing module. This allows the system to be designed and developed in an efficient manner.
  • An example of a data transmission procedure between the user-site system (managed site) and the center system (managing site) is described below with reference to FIGS. 10 to 14, for the following three cases: (1) a setting value is downloaded from the device center server 210 to a device; (2) log data is uploaded from the device monitoring server 203 a to the device center server 210; and (3) a request for counter data is transmitted from the device center server 210 to the device monitoring server 203 a.
  • Procedure of Downloading a Setting Value
  • FIG. 10 is a block diagram illustrating a process performed by the user-site system and the center system to download a setting value associated with a device. A setting value is downloaded as follows.
  • In the application system 205, a setting value information file 1002 is generated by inputting, for example via a manual operation, data specifying a device which is to be set and a setting value.
  • (1) The application system 205 establishes a session with the center server 110.
  • (2) In the center server 110, a distribution module 1001 is activated to produce a distribution file package 1001 a from a setting value information file 1002.
  • (3) The distribution module 1001 a transmits the distribution package file to the PC monitoring client module 203 d. The PC monitoring client module 203 d stores the received distribution package file as a work file.
  • (4) The user-site plug-in module 203 b examines, in scheduled intervals, the data file stored in the PC monitoring client module 203 d. If the user-site plug-in module 203 b detects that a work file is generated by the PC monitoring client module, the user-site plug-in module 203 b informs the device monitoring server of the arrival of a setting value and the user-site plug-in module 203 b transfers the setting value to the device monitoring server 203 a. The device monitoring server 203 a sets the setting value in a specified device.
  • (4-2) The user-site plug-in module 203 b transmits a message indicating the completion of the setting process to the center server via the PC monitoring client module 203 d.
  • (5) The center server 110 deletes the distribution package file 1001 a via the distribution module 1001.
  • (6) The center server 110 informs the application system 205 of the completion of the setting operation.
  • As described above, setting information associated with a device can be downloaded by transferring setting data to the device monitoring server 203 a.
  • Information indicating an occurrence of a failure in some peripheral device is transmitted as a failure event from the user-site plug-in module 203 b to the center server 110 via the PC monitoring client module 203 d in a similar manner to the procedure (4-2) described above. Thus, an event indicating a failure is dealt with by the event monitor 110 a in the center server 110 and displayed in the form of the event list.
  • Procedure of Uploading Count Information
  • FIG. 111 is a diagram illustrating a process performed between the user-site system and the center system to acquire information about a device, for example, to update count data. Device information is uploaded as follows.
  • (1) The application system 205 stores an information request command in a file and issues a message (event) which causes the center server 110 to acquire information.
  • (2) The event monitor analyzes the event received from the application system 205 and activates the distribution module 1001 to generate a distribution file package 1001 in response to the information request command.
  • (3) The center server 110 transmits the distribution package including the information request command to the PC monitoring client module 203 d. The PC monitoring server 203 d stores the received file as a work file. Herein, the term “work file” refers to a general-purpose file used in the PC/server management system and includes the same content as that of the distribution file package 1001 a.
  • (4) If the user-site plug-in module 203 b detects that the PC monitoring server 203 d has stored the file, the user-site plug-in module 203 b reads the file and transfers it to the device monitoring server 203 a. In response to the receiving the file, the device monitoring server 203 a acquires device information from a specified peripheral device and the returns the acquired device information to the user-site plug-in module 203 d.
  • (5) The user-site plug-in module 203 b stores the received device information in a file 203 e in a predetermined format. In the present embodiment, an MIF format, which is widely used in information management systems, is employed as the format of the file 203 e.
  • (6) The user-site plug-in module 203 b deletes the work file.
  • (7) The user-site plug-in module 203 b generates an event indicating that the MIF file has been created and transmits the event to the center server 110.
  • (8) In response to the receiving the event, the center server 110 deletes the distribution file package.
  • (9) In the case where the event received from the user-site plug-in module 203 b indicates that the acquisition of information has been successfully completed, the center server 110 activates the common information acquisition module 1102 to read the MIF file generated by the user-site plug-in module 203 b thereby acquiring the device information
  • (10) The common information acquisition module 1101 reads the MIF file 203 e to acquire the device information.
  • (11) The common information acquisition module 101 stores the acquired device information in an inventory database. The inventory database includes physically or logically separated databases one of which is for peripheral devices and the other is for PC/servers, so that a process can be properly performed depending upon the device.
  • (12) The center server then makes the MIF file 203 at the user site removed.
  • (13) The center server informs the application of the completion of the process.
  • In the above-described manner, the device information acquired by the device monitoring server 203 a can be transferred to the center server 110.
  • Procedure of Uploading Log Data
  • FIG. 12 is diagram illustrating a process of uploading log data from the user-site system to the center system. In the present embodiment, the uploading of log data is performed as follows.
  • (1) The device monitoring server 203 a transmits, to the user-site plug-in module 203 b, a message indicating that an error or a warning has been detected or indicating that errors or warnings have been detected a greater number of times than a predetermined threshold value.
  • (2) The device monitoring server 203 a issues the above-described warning event to the user-site plug-in module 203 d.
  • (3) The user-site plug-in module 203 b stores the log data in a file 203 e in the MIF format. As described earlier, the MIF format is a data/file format which is widely used in information management systems.
  • (4) The user-site plug-in module 203 b generates an event indicating that the MIF file has been generated and transmits it to the center server 110.
  • (5) Upon receiving the event, the center server 110 activates the common information acquisition module 1201.
  • (6) The common information acquisition module 1201 acquires the log data by reading the MIF file 203 e generated by the user-site plug-in module 203 b.
  • (7) The common information acquisition module 101 stores the acquired device information in the inventory database 109.
  • (8) The center server makes the MIF file 203 e at the user site deleted.
  • (9) The center server informs the application of the completion of the process.
  • In the above-described manner, the log data file generated by the device monitoring server 203 a is acquired by the center server 110.
  • Procedure Performed by the Device Center Server
  • The processes performed by the center server 110, the device information processing module 901, the user-site plug-in module 203 b, and the PC monitoring client module 203 d are briefly described below. FIG. 13 is a flow chart of a process performed by the center server 110 in response to receiving an event. In response to receiving an event, the process shown in FIG. 13 is started. Note that the terms “message” and “event” are not distinguished strictly. That is, the term “event” is used to describe a message indicating an occurrence of an event.
  • First, the received event is analyzed (step S1310) to determine where the event is from (step S1302). If the event has been issued by the PC monitoring client module 203 d, the event is dealt with by the event monitor. However, if the event is a failure event, the event is displayed in the form of an event list (step S1303).
  • Thereafter, it is determined whether or not the event is associated with a peripheral device, that is, whether or not the event has been issued by the user-site plug-in module 203 b (step S1034). If the event is associated with a peripheral device, the device information processing module performs a process depending upon the event. The detailed procedure is described in FIGS. 14 to 16. On the other hand, if the event is not associated with any peripheral device, the event is dealt with by the center server 110.
  • In the case where the event has been issued by a back-end system, that is, an application system, it is determined whether the event is a request for acquiring information (step S1305). If yes, an information acquisition request is issued to the user-site plug-in module 203 b (step S1039). The information acquisition request is issued by generating a distribution file package using the distribution module 1001.
  • If the event is not a request for acquiring information, it is determined whether the event is a request for downloading data (step S1306). If no, a process is performed depending upon the event, and the process waits for another event.
  • In the case where the event is a request for downloading data, data requested to be downloaded is acquired from the back-end system (step S1037), and the download data is transmitted to the user-site plug-in module 203 b (step S1308).
  • Procedure Performed by the Device Information Processing Module
  • In the case where it is determined in step S1304 in FIG. 13 that the event is associated with a peripheral device, the event is analyzed to further determine whether (1) the event is a notice of completion of downloading, (2) the event is a notice of completion of acquisition of device information, or (3) the event is a request for uploading log data. The details of these processes are illustrated in the flow chart shown in FIGS. 14 to 16.
  • Completion of Downloading
  • FIG. 14 is a flow chart of a process performed by a device information processing module 901 in response to a download end event. If a notice of completion of downloading is received, the distribution file package 1001 a is deleted (step S1401), and the back-end system is notified of the completion of downloading (step S1402).
  • Acquisition of Device Information
  • FIG. 15 is a flow chart of a process performed by the device information processing module 901 in response to notification of acquisition of device information (counter value).
  • First, the distribution file package 1001 a generated in response to the information acquisition request is deleted (step S1501). Thereafter, if the data has been successfully acquired, the information acquisition module 1101 is activated (step S1503), and a request for an MIF file in which device information is stored is issued to the device monitoring server 203 a. As a response to the request, the MIF file is received (step S1504).
  • The received file is stored in the inventory database 109 (step S1505), and a request for deleting the MIF file is transmitted to the device monitoring server 203 a (step S1506). Finally, the back-end system is informed of the completion of acquisition of the device information (step S1507).
  • On the other hand, in the case where an error is detected in step S1502, the back-end system is informed of the error (step S1508).
  • In the above-described manner, the device information described in the MIF file is acquired from the device monitoring server 203 a.
  • Uploading of Log Data
  • FIG. 16 is a flow chart of a process performed by the device information processing module 901 in response to a log data upload request.
  • If a request for uploading log data is received, the common information processing module 1201 is activated (step S1601), and a request for transmitting an MIF file in which log data is described is issued to the device monitoring module 203 a (step S1602).
  • As a response to the request, the MIF file is received (step S1603) and stored in the inventory database 109 (step S1604). Thereafter, a request for deleing the MIF file is issued to the device monitoring server 203 a (step S1605). When the above process is completed, the back-end system is notified of the completion of the process (step S1606).
  • Procedure Performed by the Device Monitoring Server
  • FIG. 17 is a flow chart of a process performed by a user-site plug-in module 203 b in response to receiving a message or an event issued to the plug-in module. If a message is issued by the center server 110 to the user-site plug-in module 203 b, the message is stored by the PC monitoring client module 203 d in a predetermined storage area. Therefore, the user-site plug-in module 203 b always monitors or checks at fixed intervals the PC monitoring client module 203 d to determine whether a message addressed to the user-site plug-in module 203 b has arrived.
  • If a message is detected, it is determined whether the message is from the device monitoring server 203 a (step S1701). If yes, the message is analyzed (step S1702) to determine whether the message is a warning or the message indicates a change in value beyond a threshold, log data is written in an MIF file, and an event is issued to the center server 110 via the PC monitoring client module 203 d to notify that the log file will be uploaded (step S1705).
  • If the message indicates neither a warning nor a change beyond a threshold, it is determined whether the event indicates an error (step S1706). If yes, a message indicating a failure event is generated (step S1707), and the process goes to step S1705.
  • In the case where the message is not from the device monitoring server 203 a, it is determined that the message has been issued by the center server 110. In this case, the data written by the PC monitoring client module 203 d in the predetermined storage area is read (step S1708), and a process is performed depending upon the content of the data, as shown in detail in FIG. 18.
  • FIG. 18 is a flow chart of a process performed by the user-site plug-in module 203 b in response to a message received from a center server 1101.
  • First, it is determined whether the message is download data (step S1801). If yes, the device monitoring server 203 a is notified of the reception of the download data (step S1802), and the data is transferred to the device monitoring server 203 a (step S1803). After transferring the data, the data is deleted (step S1804), and an event indicating the completion of the downloading process is issued to the center server 1101 (step S11805).
  • In the case where the message is not download data, it is determined whether the message is a request for acquiring device information (step S1806). If yes, a request for acquiring device information is issued to the device monitoring server 203 a (step S11807).
  • As a response to the request, the device information is received from the device monitoring server 203 a (step S1808). The received device information is stored in an MIF file (step S1809), and a message indicating that the device information has been acquired is issued to the center server 110.
  • Procedure Performed by the PC Monitoring Client Module
  • FIG. 19 is a flow chart of a process performed by a PC monitoring client module
  • In FIG. 19, it is determined where the received data is addressed (step S1901). If the message is addressed to a general-purpose computer in the PC/servers, the data is transferred to a specified process (step S1902). In the case where the message is addressed to the user-site plug-in module, the data is written in the predetermined storage area described above.
  • In the system according to the present embodiment, as described above, a monitoring system originally designed to monitor general-purpose computers can be used to also manage peripheral devices installed at the same site at which general-purpose computers are installed. This makes it possible to monitor, at the managing site, general-purpose computers and peripheral devices in a similar manner. Furthermore, it also becomes possible, at the managing site, to acquire information about a peripheral device and to set a parameter of a peripheral device via the monitoring system. Furthermore, it is possible to transmit log data from the managed site to the managing site.
  • The module which is added to the monitoring system originally designed to monitor general-purpose computers to achieve the capability of monitoring peripheral devices can be realized by means of software without needing additional special hardware and thus without causing increases in the installation space, the device cost, the maintenance cost, and the hardware size.
  • The present invention is not limited to a system in which managing information associated with peripheral devices is adapted to the software designed to manage general-purpose computers (PC/servers), but the present invention may also be applied to a system in which management information associated with PC/servers is adapted to the software for managing peripheral devices. In this case, for example, the configuration shown in FIG. 9 may be modified such that the peripheral devices 201 and the PC/servers 202 are replaced with each other; the device monitoring server 203 a and the PC monitoring client module 203 d are replaced with each other; the MIF file 203 e is described in a format specific to a device; the user-site plug-in module 203 b is constructed so as to have the capability of converting data from a format for use by the PC/servers into a format for use by the device; the center server performs a process associated with a peripheral device; the device processing module 901 performs a process associated with a PC/server; and the device center issues an event.
  • Request for Service Operation
  • In the remote site managing system according to the first or second embodiment described above, when a failure occurs in a device installed in a customer's office, a message indicating the occurrence of the failure is sent to the center system. In response, the failure is dealt with as described below. In particular, when the failure cannot be dealt with by the customer, a service operation request is generated to request a service company, a service dealer, or a service organization to deal with the failure.
  • FIG. 20 is a flow chart illustrating a process performed by the application system at the managing site (center system) to deal with a failure in response to receiving a message indicating the occurrence of the failure.
  • If a failure occurs in some PC/serer device or in some peripheral device at a managed site, a failure event is transmitted from a device monitoring server or a PC monitoring client module to a device center server or a center server. Furthermore, the failure event is transmitted to the application system (step S2001). FIG. 21 shows a data structure of a failure event. The data of a failure event includes the device number (serial number) of a device which encountered a failure, the date/time at which the failure occurred, a failure code indicating the failure, and the device type (PC or peripheral device) of a device having the failure.
  • The application system acquires the device number (serial number), the date/time at which the failure occurred, the failure code, and the device type (PC or peripheral device) from the failure event data (step S2002). As required, information is displayed on the screen as shown in FIG. 21 or 22.
  • In the example shown in FIG. 22, a failure list is displayed on the screen. The failure list describes, for each failure, the date/time at which the failure occurred, the device type (PC or peripheral device) of a device which encountered the failure, the failure code indicating the type of the failure, and the device number (serial number) of the device which encountered the failure.
  • In the example shown in FIG. 23, information about a failure which occurred in a particular device is displayed on the screen. User information or customer information is displayed on the upper and left side of the screen, and device information of the device having the failure is displayed on the upper and right side. The history of failures which have occurred in the device installed in the customer's office is displayed on the bottom. The history of failures describes, for each failure, the date/time at which the failure occurred, the failure code indicating the failure, the failure type, the location in the device at which the failure occurred, and the note.
  • Who should deal with the failure is determined on the basis of the failure code and the device type (PC or peripheral device) using a failure code master table such as that shown in FIG. 24. The failure code master table such as that shown in FIG. 24 is stored in the inventory database 109 shown in FIG. 2.
  • As shown in FIG. 24, the failure code master table describes, for each failure type, the failure code of the failure, the device type (PC or peripheral device), who should deal with the failure (whether the customer or a service person), and the manner of dealing with the failure.
  • In step S2003, retrieval is performed using a failure code and a device type (PC or a peripheral device) as a key to determine who should deal with the failure. If it is determined that the customer should deal with the failure, the process proceeds to step S2004. However, if it is determined that a service company should deal with the failure, the process proceeds to step S2006.
  • In step S2004, customer information is acquired on the basis of the device number (serial number) described in the failure event. To acquire the customer information, the customer code and the customer sub-code corresponding to the device number (serial number) are first determined from a device number (serial number) master table such as that shown in FIG. 25. The device number (serial number) master table describes, for each device, the device number (serial number) of the device, the manufacturer name of the device, the customer code and the customer sub-code of the customer possessing the device, the location where the device is installed, and the service company code which provides maintenance service for that device.
  • After determining the customer code and the customer sub-code, the customer information corresponding to the customer code and the customer sub-code is read from a customer master table such as that shown in FIG. 26. The customer master table describes, for each customer, the customer code of the customer, the customer sub-code of the customer, the company name of the customer, the department/section name of the customer, the address of the customer, the telephone number of the customer, the facsimile number of the customer, the electronic mail address of the customer, the person at the customer who is responsible for the device, the contract level of the customer, the code of the service company which provides maintenance service for PC devices of the customer, and the code of the service company which provides maintenance service for peripheral devices of the customer. Customer codes and customer sub-codes are used to distinguish different departments/sections of the same company. More specifically, a customer code indicates a company and a customer sub-code indicates a department/section.
  • Finally, the manner of dealing with the failure corresponding to the failure code is read from the failure code master table shown in FIG. 24, and displayed on the display screen as shown in FIG. 27 (step S2005). In the example shown in FIG. 27, information displayed on the screen includes the user information or customer information, the device information of the device having the failure, and the manner of dealing with the failure. When a human operator of the center system views the screen, the operator makes a telephone call to the customer to tell that a failure has occurred in the device and how to deal with the failure.
  • In step S2006 and steps following that, a request for a service operation is generated. First, a trouble ticket ID (also referred to as a trouble ID) is issued (step S2006). A trouble ticket ID is issued for each service operation request to identify the service operation request. Each time a new trouble ticket ID is issued, it is registered in a trouble ticket ID table such as that shown in FIG. 28, and the contents of service operation request and the progress of the service operation are managed. For example, a trouble ticket ID is given as “date+serial number”.
  • As shown in FIG. 28, the trouble ticket table describes, for each service operation request, the trouble ticket ID of the service operation request, the status (progress) of the service operation, the date/time at which the service operation request was issued, the date/time at which the service operation request was dealt with (the service operation was performed), the customer code and the customer sub-code of the customer who issued the service operation request, the device number (serial number) of the device requested to be dealt with, the service company code of the service company which performed the requested service operation, the name of the person who performed the requested service operation, the cause of the failure dealt with in response to the service operation request, and the details of the service operation performed in response to the service operation request.
  • Thereafter, a service operation request is generated (step S2007). The details of the process of generating a service operation request will be described later. After generation of the service operation request, it is transmitted to the service company by means of an electronic mail (step S2008). Herein, the service operation request may be described in the electronic mail itself, or the service operation request may be attached to the electronic mail.
  • In response, the service company performs a service operation and issues a service operation report via an electronic mail (step S2008). Herein, the service operation report may be described in the electronic mail itself or the service operation report may be attached to the electronic mail.
  • In any case, the trouble ticket ID assigned to the service operation request is described in the “Subject” field of the electronic mail so that the trouble ticket ID can be recognized (step S2009). In the trouble ticket table shown in FIG. 28, the status corresponding to the recognized trouble ticket 1D is changed to “done”. Furthermore, the cause described in the service operation report and the message (text data) described in the “action taken” field are copied into the “cause” field and the “action taken” field of the trouble ticket table.
  • Generation and Transmission of a Service Operation Request
  • FIG. 29 is a flow chart illustrating the details of the process performed in step S2007 in FIG. 20 to generate and transmit the service operation request. First, a template file of a service operation request/report is read (step S2901). In the present embodiment, a service operation request and a service operation report are described on a single sheet. Alternatively, a service operation request and a service operation report may be described separately on different sheets.
  • FIG. 30 illustrates an example of a template file of a service operation request/report. The template file includes blank fields in which a trouble ticket ID (trouble ID), a date/time at which a failure occurred, user information of a customer, device information of a device in which the failure occurred, a failure code, an action to be taken to deal with the failure, a cause, and an action taken will be described.
  • Thus, the trouble ticket ID issued in step S2006 shown in FIG. 20 is copied in the corresponding field (step S2902) of the template. Thereafter, the date/time acquired in step S2002 in FIG. 20 is copied in the template (step S2903). Furthermore, customer information (user information) is read in a similar manner to step S2004 shown in FIG. 20 and copied in the template (step S2904). Device information is then read in a similar manner to step S2004 shown in FIG. 20 and copied (step S2905). Thereafter, the manner of dealing with the failure is read in a similar manner to step S2005 shown in FIG. 20 and copied together with the failure code obtained in step S2002 (step S2906).
  • Thereafter, the contract level is detected from the customer information (step S2907). In the case where the contract level is determined as level 1, it is required to urgently deal with the failure, and thus the time limit is set to a 2-hours-later time and described in the template (step S2908). In the case where the contract level is determined as level 2, the time limit is set to a 4-hours-later time and described in the template (step S2909). In the case where the contract level is determined as level 4, the time limit is set to the next day and described in the template (step S2910).
  • Thereafter, a forwarding address of the service operation request, for example, the electronic mail address of the service company, is read from a service company master table such as that shown in FIG. 31. To this end, the service company code is first identified. In the case where the device type (PC or a peripheral device) is determined in step S2002 in FIG. 20 as a “PC”, the PC service company code is read from the customer master table shown in FIG. 26. If the device type is determined as a peripheral device, the peripheral device service company code is read, and the electronic mail address corresponding to the service company code is read from the table shown in FIG. 31.
  • As shown in FIG. 31, the service company master table describes, for each service company, the service company code of the service company, the type of service provided by the service company, the company name of the service company, the department/section name of the service company, the address of the service company, the telephone number of the service company, the facsimile number of the service company, the electronic mail address of the service company, and the name of a service person of the service company. In the present embodiment, the service company code is assigned differently for each department/section of respective service companies.
  • Finally, the trouble ticket ID is described in the subject field of the electronic mail, and the electronic mail is transmitted to the electronic mail address acquired in step S2911 together with the attached template file filled of the service operation request/report filled with the information in the above-described manner (step S2912).
  • Generation and Transmission of a Service Operation Report
  • A computer installed in the service company receives the electronic mail and the service operation request/report attached thereto (step S2050). The contents of the attached service operation request/report are displayed on a display. A service person reads the contents of the service operation request/report and visits the customer to perform the service operation.
  • The computer of the service company then generates a service operation report and transmits it. FIG. 32 is a flow chart illustrating the process of generating and transmitting a service operation report. First, the file of the service operation request/report received in step S2050 in FIG. 20 is read (step S3201). Furthermore, a message indicating the cause of the failure, and a message indicating the action taken to deal with the failure, the name of the service person who dealt with the failure are input via a keyboard so as to describe them in the file of the service operation request/report (step S3202). Furthermore, the trouble ticket ID of the service operation request is described in the subject field of the electronic mail, and the electronic mail is transmitted together with the attached service operation request/report generated in the above-described manner.
  • Generation of a Device Operation Report
  • The remote site managing system also has the capability of generating and transmitting a device operation report as described below. FIG. 35 illustrates an example of a template file of a device operation report. In the device operation report, the total number of copied sheets during the present month, the numbers of copied sheets for the respective copying modes, the numbers of copied sheets for the respective sheet sizes, the failure history, and other information are described.
  • FIG. 33 is a flow chart illustrating a process performed by an application system at a managing site (center system) to issue a device operation report to a customer.
  • A request command is transmitted to the device monitoring server at the managed site on an once-every-month basis to acquire counter information of a particular device (step S3301). The received counter information is stored in a counter information table such as that shown in FIG. 34. As shown in FIG. 34, in the counter information table, device operation information is described for each month. More specifically, the device operation information described in the counter information table includes the device number (serial number) of the device, the month of the report, and the cumulative values as measured for that month in terms of the following numbers of sheets: the total counter value, the number of sheets printed on both-sides, the number of sheets printed in a multiple mode, the number of sheets printed in a 2-in-1 mode, the number of sheets printed in a 4-in-1 mode, the number of sheets output via facsimile, the number of sheets printed in accordance with print data output from a host computer, the number of scanned-and-transmitted sheets, the number of transmitted electronic mails, and the numbers of copied or printed sheets for the respective sheet sizes. That is, the counter information includes data indicating the respective counter values associated with the numbers described above.
  • The total counter value as measured for the previous month is then subtracted from the total counter value as measured for the present month to calculate the total number of sheets copied or printed during the present month and the calculated number is described in the template file of the device operation report. Similarly, the numbers of sheets copied or printed in the respective copying modes during the present month are described (step S3304). Thereafter, the ratios (in percents) of the numbers of sheets copied or printed in the respective modes to the total number of sheets are described in the template file (step S3305).
  • The trouble ticket table is then searched using the customer code, the customer sub-code, and the date/time=the present month as retrieval keys to detect trouble ticket IDs corresponding to troubles which occurred during the present month. The data indicating the detected trouble ticket IDs is described in the failure history (step S3306).
  • Thereafter, it is determined whether or not two or more of the detected trouble ticket IDs are associated with the same device number (step S3310). Furthermore, it is determined whether there is a trouble ticket ID whose status of the service operation request is “not completed” (step S3308). It is further determined whether there is a device which had, in the past, a failure that has already been dealt with (step S3309).
  • The device number corresponding to the trouble ticket ID is described depending upon the result of the determination. More specifically, in step S3310, the device number of a device which has encountered a failure two or more times or the device number corresponding to a trouble ticket ID which has not yet been dealt with is described in the field “There is a tendency for the frequency of troubles to increase. Observation in required for a while”. In step S3311, the device number is described in the field “There is no problem at all”. In step S3312, the device number is described in the field “Although a trouble occurred, the trouble has been resolved”.
  • The present date is then described in the template file (step S3313). Finally, the template file is saved in the HTML format and transmitted to the customer (step S3314). In step S3314, the device operation report in the HTML (Hyper Text Markup Language) format may be transmitted as data attached to an electronic mail, or a URL (Uniform Resource Location) address indicating the location of the device operation report in the HTML format is noticed via an electronic mail so that the customer can obtain the device operation report via a WWW browser.
  • Other Embodiments
  • Furthermore, the objects of the present invention may also be achieved by supplying a storage medium, on which a software program implementing the functions of any of the embodiments described above is stored, to a system or an apparatus whereby a computer (CPU or MPU) in the system or apparatus reads and executes the program code stored on the storage medium.
  • In this case, it should be understood that the program code read from the storage medium implements the novel functions of invention and thus the storage medium storing the program code falls within the scope of the present invention.
  • The data of device information may be stored on a HDD installed in an image processing apparatus or an image data expanding apparatus, an externally connected storage medium, or a server or the like which can be accessed from the image data expanding apparatus. The data of device information may be described in an arbitrary form determined by a user.
  • Specific examples of such a storage medium for storing the program code include a floppy disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a magnetic tape, a non-volatile memory card, and a ROM.
  • Furthermore, the scope of the present invention includes not only such a system in which the functions of any embodiment described above are implemented simply by reading and executing a program code on a computer but also a system in which a part of or the whole of process instructed by the program code is performed using an OS (operating system) on the computer.
  • Furthermore, the scope of the present invention also includes a system in which a program code is transferred once from a storage medium into a memory provided in a function extension board inserted in a computer or provided in a function extension unit connected to the computer, and then a part of or the whole of process instructed by the program code is performed by a CPU or the like in the function extension board or the function extension unit thereby implementing the functions of any embodiment described above.
  • In the case where the present invention is implemented on a storage medium such as that described above, program codes corresponding to one or more of the flow charts (described above with reference to FIGS. 5 to 7, 13 to 20, 29, and 32) are stored on the storage medium.
  • As described above in detail, the present invention makes it possible to manage, at a managing site, both types of devices, that is, PC/servers and peripheral devices installed in an office, in an unified fashion.
  • In particular, the managing site system can automatically receive information indicating a failure which has occurred or indicating a high possibility that a failure will occur in some of PC/servers or peripheral devices installed in the office and can provide maintenance services without troubling the customer.
  • Furthermore, transmission of a request to a maintenance service company and reception of a service operation report from the service company can be performed in an unified fashion. This allows a customer to receive maintenance service for various devices simply by making a contract with one management site without having to make contracts with various service companies.
  • It is also possible to automatically generate a report about the operation of a particular device installed in an office, on the basis of the counter information and the history of failures and transmit it to a customer.
  • While the present invention has been described with reference to what are presently considered to be the preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. On the contrary, the invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.

Claims (20)

  1. 1-49. (canceled)
  2. 50. A device managing apparatus for managing a device via a network, said device managing apparatus comprising:
    failure detection means for receiving data indicating an occurrence of a failure in the device;
    generating means for generating data indicating a request for a service operation in accordance with reception of the data by said failure detection means;
    selection means for selecting a company among a plurality of companies which should perform a service operation upon the device;
    transmission control means for transmitting the data indicating the request for the service operation generated by said generating means to the company selected by said selection means;
    issuing means for issuing an identifier assigned to the request for the service operation; and
    storing means for storing information about each of a plurality of the requests for the service operation, said storing means storing, as that information, the issued identifier assigned to the request for the service operation, the selected company which should perform the service operation corresponding to the request for the service operation and the status of the service operations corresponding to the request.
  3. 51. A device managing apparatus according to claim 50, further comprising receiving means for receiving data indicating a service operation report which is returned from the company in response to the transmitted data indicating the request for the service operation.
  4. 52. A device managing apparatus according to claim 51, wherein
    said transmission control means controls the transmission such that the data indicating the request for the service operation is transmitted together with the identifier issued by said issuing means,
    said receiving means receives the data indicating the request for the service operation together with the identifier transmitted by said transmission control means, and
    said management means changes the status of the service operation corresponding to the request which corresponds to the identifier received by said receiving means, in accordance with the data indicating the service operation report received by said receiving means.
  5. 53. A device managing apparatus according to claim 50, wherein
    said failure detection means receives device information identifying a device detected as having a failure, and
    said selection means selects a company on the basis of the received device information.
  6. 54. A device managing apparatus according to claim 50, wherein
    said failure detection means receives failure information identifying a detected failure, and
    said generating means describes the received failure information in the data indicating the request for the service operation.
  7. 55. A device managing apparatus according to claim 50, further comprising:
    determining means for determining who should deal with the failure detected by said failure detection means; and
    display control means for, when said determining means determines that a customer possessing said device should deal with the failure, displaying, on a display unit, customer information associated with that customer and a message indicating the manner of dealing with the detected failure.
  8. 56. A device managing apparatus according to claim 55, wherein said selection means selects a company when said determining means determines that a company should deal with the failure.
  9. 57. A device managing program stored in a computer-readable storage medium and executed by a computer to manage a device via a network, said program comprising:
    a failure detection step, of receiving data indicating an occurrence of a failure in the device;
    a generation step, of generating data indicating a request for a service operation in accordance with reception of the data in said failure detection step;
    a selection step, of selecting a company among a plurality of companies which should perform a service operation upon the device;
    a transmission control step, of transmitting the data indicating the request for the service operation generated in said generation step to the company selected in said selection step;
    an issuing step, of issuing an identifier assigned to the request for the service operation; and
    a storage step, of, storing information about each of a plurality of the requests for the service operation, said storing step including storing, as that information, the issued identifier assigned to the request for the service operation, the selected company which should perform the service operation corresponding to the request for the service operation and the status of the service operation corresponding to the request.
  10. 58. A method for managing a device via a network, said method comprising:
    a failure detection step, of detecting an occurrence of a failure in the device;
    a generation step, of generating data indicating a request for a service operation in accordance with detecting a failure in said failure detection step;
    a selection step, of selecting a company among a plurality of companies which should perform a service operation upon the device;
    a transmission control step, of transmitting the data indicating the request for the service operation generated in said generation step to the company selected in said selection step;
    an issuing step, of issuing an identifier assigned to the request for the service operation; and
    a storage step, of storing information about each of a plurality of the requests for the service operation, said storage step including storing, as that information, the issued identifier assigned to the request for the service operation, the selected company which should perform the service operation corresponding to the request for the service operation and the status of the service operation corresponding to the request.
  11. 59. A device managing method according to claim 58, further comprising a receiving step, of receiving data indicating a service operation report which is returned from a company in response to the transmitted data indicating the request for the service operation.
  12. 60. A device managing method according to claim 59, wherein
    said transmission control step includes controlling the transmission such that the data indicating the request for the service operation is transmitted together with the identifier issued in said issuing step,
    said receiving step includes receiving the data indicating the request for the service operation together with the identifier transmitted in said transmission control step, and
    said management step includes changing the status of the service operation corresponding to the request which corresponds to the identifier received in said receiving step, in accordance with the data indicating the service operation report received in said receiving step.
  13. 61. A device managing method according to claim 58, wherein
    said failure detection step includes acquiring device information identifying a device detected as having a failure, and
    said selection step includes selecting the company on the basis of the received device information.
  14. 62. A device managing method according to claim 58, wherein
    said failure detection step includes acquiring failure information identifying a detected failure, and
    said generation step includes describing the received failure information in the data indicating the request for the service operation.
  15. 63. A device managing method according to claim 58, further comprising:
    a determining step, of determining who should deal with the failure detected in said failure detection step; and
    a display control step, of, when it is determined in said determining step that a customer possessing the device should deal with the failure, displaying, on a display unit, customer information associated with the customer and a message indicating the manner of dealing with the detected failure.
  16. 64. A device managing method according to claim 63, wherein said selection step includes selecting the company when it is determined in said determining step that a company should deal with the failure.
  17. 65. An information processing apparatus comprising:
    a receiver adapted to receive data indicating a failure in a device;
    a controller adapted to select a company among a plurality of companies which should perform a service operation upon the device;
    a sender adapted to send a request for the service operation to the company selected by said controller; and
    storage adapted to store information indicating the status of the service operation corresponding to the request sent by said sender.
  18. 66. A method for managing a service operation comprising the steps of:
    detecting a failure in a device;
    selecting a company among a plurality of companies which should perform a service operation upon the device;
    sending a request for the service operation to the company selected in said selecting step; and
    storing information indicating the status of the service operation corresponding to the request sent in said sending step.
  19. 67. A method according to claim 66, further comprising the steps of receiving a service operation report which is returned from the selected company in response to the sent request for the service operation and changing, in accordance with the reception of the service operation report, the status of the service operation to a status in which the service operation is done.
  20. 68. A method according to claim 67, wherein
    in said sending step, the request for the service operation and an identifier corresponding to the request for the service operation are sent to the selected company,
    in said receiving step, the service operation report and the identifier are received from the selected company, and
    in said changing step, the status of the service operation corresponding to the request which corresponds to the received identifier is changed to the status in which the service operation is done.
US11269769 2000-11-17 2005-11-09 Apparatus for managing a device, program for managing a device, storage medium on which a program for managing a device is stored, and method of managing a device Abandoned US20060107088A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2000351263A JP4185661B2 (en) 2000-11-17 2000-11-17 The device management apparatus, device management program, a recording medium device management program is stored, and a device management method
JP2000-351263 2000-11-17
US09985225 US7017071B2 (en) 2000-11-17 2001-11-02 Apparatus for managing a device, program for managing a device, storage medium on which a program for managing a device is stored, and method of managing a device
US11269769 US20060107088A1 (en) 2000-11-17 2005-11-09 Apparatus for managing a device, program for managing a device, storage medium on which a program for managing a device is stored, and method of managing a device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11269769 US20060107088A1 (en) 2000-11-17 2005-11-09 Apparatus for managing a device, program for managing a device, storage medium on which a program for managing a device is stored, and method of managing a device

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09985225 Division US7017071B2 (en) 2000-11-17 2001-11-02 Apparatus for managing a device, program for managing a device, storage medium on which a program for managing a device is stored, and method of managing a device

Publications (1)

Publication Number Publication Date
US20060107088A1 true true US20060107088A1 (en) 2006-05-18

Family

ID=18824351

Family Applications (2)

Application Number Title Priority Date Filing Date
US09985225 Active 2023-05-25 US7017071B2 (en) 2000-11-17 2001-11-02 Apparatus for managing a device, program for managing a device, storage medium on which a program for managing a device is stored, and method of managing a device
US11269769 Abandoned US20060107088A1 (en) 2000-11-17 2005-11-09 Apparatus for managing a device, program for managing a device, storage medium on which a program for managing a device is stored, and method of managing a device

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09985225 Active 2023-05-25 US7017071B2 (en) 2000-11-17 2001-11-02 Apparatus for managing a device, program for managing a device, storage medium on which a program for managing a device is stored, and method of managing a device

Country Status (2)

Country Link
US (2) US7017071B2 (en)
JP (1) JP4185661B2 (en)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030233441A1 (en) * 2002-05-08 2003-12-18 Yoko Nishiyama Information distribution system
US20050210161A1 (en) * 2004-03-16 2005-09-22 Jean-Pierre Guignard Computer device with mass storage peripheral (s) which is/are monitored during operation
US20070055725A1 (en) * 2005-09-07 2007-03-08 Gianluca Bernardini Method, system and computer program for providing web pages based on client state
US20070266138A1 (en) * 2006-05-09 2007-11-15 Edward Spire Methods, systems and computer program products for managing execution of information technology (it) processes
US20080082990A1 (en) * 2006-09-30 2008-04-03 Samsung Electronics Co., Ltd. Apparatus and method for interfacing in a communication system
US20080126870A1 (en) * 2006-06-30 2008-05-29 Kabushiki Kaisha Toshiba Maintenance system, method of controlling maintenance system, server, record medium in which program used for server is recorded, computer and record medium in which program used for computer is recorded
US20080172421A1 (en) * 2007-01-16 2008-07-17 Microsoft Corporation Automated client recovery and service ticketing
US20090300436A1 (en) * 2008-06-03 2009-12-03 International Business Machines Corporation Synchronizing device error information among nodes
US20100060436A1 (en) * 2008-09-10 2010-03-11 International Business Machines Corporation Microphone diagnostic inside system with voip alerting and monitoring
US20120163194A1 (en) * 2009-08-28 2012-06-28 Telefonaktiebolaget Lm Ericsson(Publ) Handling Alarms Based On User Session Records
US20130305102A1 (en) * 2012-05-11 2013-11-14 James Malnati Automated trouble ticket generation
US9306799B2 (en) 2012-03-19 2016-04-05 Ricoh Company, Limited Information processing apparatus, information processing method, and computer program product

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002163163A (en) * 2000-09-12 2002-06-07 Canon Inc Remote-site management system
US20030145128A1 (en) * 2002-01-25 2003-07-31 Baird Roger T. Mapping managing devices to managed devices
JP2003256301A (en) * 2002-02-28 2003-09-12 Canon Inc System and program for network management, and display method
WO2003081359A1 (en) * 2002-03-27 2003-10-02 Kabushiki Kaisha Toshiba centralized PLANT-monitoring controlLER and method
US7334166B1 (en) 2002-10-04 2008-02-19 American Megatrends, Inc. Method, system, and apparatus for providing and utilizing server-side entry points for use in diagnostics on-demand services
US7231549B1 (en) * 2002-10-04 2007-06-12 American Megatrends, Inc. Method and apparatus for providing on-demand computer diagnostics
US7200775B1 (en) 2002-10-04 2007-04-03 American Megatrends, Inc. Method and data structures for use in providing on-demand computer diagnostics
US7712083B2 (en) * 2003-08-20 2010-05-04 Igt Method and apparatus for monitoring and updating system software
US8392545B2 (en) * 2004-07-01 2013-03-05 Nokia Corporation Device management system
US7719965B2 (en) * 2004-08-25 2010-05-18 Agilent Technologies, Inc. Methods and systems for coordinated monitoring of network transmission events
JP4125274B2 (en) * 2004-08-26 2008-07-30 キヤノン株式会社 Image output device and a storage medium, and program information processing method, and computer-storing readable program
EP1641237A3 (en) * 2004-09-22 2006-07-26 Sharp Corporation Image processing apparatus and image processing system
US8191135B2 (en) * 2005-01-20 2012-05-29 International Business Machines Corporation Secured web based access of failed flows in an integration server
US20060271656A1 (en) * 2005-05-24 2006-11-30 Yuichi Yagawa System and method for auditing storage systems remotely
US20070033276A1 (en) * 2005-08-08 2007-02-08 Southern Company Services, Inc. Application portfolio and architecture research tool
US7506211B2 (en) * 2005-09-13 2009-03-17 International Business Machines Corporation Automated atomic system testing
JP2007094455A (en) * 2005-09-26 2007-04-12 Brother Ind Ltd Network system, printer, and printer control program
DE102006006438A1 (en) * 2006-02-13 2007-08-16 Heidelberger Druckmaschinen Ag Method for the secure transmission of operational data
DE102006022710A1 (en) * 2006-05-12 2007-11-15 Heidelberger Druckmaschinen Ag Service platform for maintenance of machinery
US8578335B2 (en) * 2006-12-20 2013-11-05 International Business Machines Corporation Apparatus and method to repair an error condition in a device comprising a computer readable medium comprising computer readable code
US8312135B2 (en) * 2007-02-02 2012-11-13 Microsoft Corporation Computing system infrastructure to administer distress messages
JP2009053905A (en) * 2007-08-27 2009-03-12 Chugoku Electric Power Co Inc:The Device management system, device management method, and device management program
US20090138510A1 (en) * 2007-11-28 2009-05-28 Childress Rhonda L Method and apparatus for associating help desk ticket with affected data processing system
US9053135B2 (en) * 2007-12-13 2015-06-09 Verizon Patent And Licensing Inc. Device level performance monitoring and analysis
US20090228962A1 (en) * 2008-03-06 2009-09-10 Sharp Laboratories Of America, Inc. Access control and access tracking for remote front panel
US8448015B2 (en) 2008-06-17 2013-05-21 My Computer Works, Inc. Remote computer diagnostic system and method
US20120079125A1 (en) * 2010-09-23 2012-03-29 Mark Nixon Service oriented framework for communicating with devices in a process control system
JP2013054531A (en) * 2011-09-02 2013-03-21 Nomura Research Institute Ltd Incident management system
JP2014067399A (en) * 2012-09-10 2014-04-17 Ricoh Co Ltd Report generation device, report generation system, and program
US20140149982A1 (en) * 2012-11-28 2014-05-29 Red Hat Israel, Ltd. Self-monitored commands
US20140222942A1 (en) * 2013-02-04 2014-08-07 Hon Hai Precision Industry Co., Ltd. Remote control system and method
JP5745557B2 (en) * 2013-03-15 2015-07-08 株式会社サカエ Communication type shredder and shredder management system using the same
CN105281948A (en) * 2015-09-08 2016-01-27 小米科技有限责任公司 Event processing method and apparatus
JP2017135593A (en) 2016-01-28 2017-08-03 キヤノン株式会社 Image processing device, control method thereof, and program

Citations (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5666481A (en) * 1993-02-26 1997-09-09 Cabletron Systems, Inc. Method and apparatus for resolving faults in communications networks
US5815652A (en) * 1995-05-31 1998-09-29 Hitachi, Ltd. Computer management system
US5854828A (en) * 1996-08-20 1998-12-29 Dell U.S.A., L.P. Telephone customer support utility
US5896440A (en) * 1994-05-26 1999-04-20 Gte Service Corporation System and method for providing a unified communications link between divergent communication networks
US6026500A (en) * 1997-05-13 2000-02-15 Electronic Data Systems Corporation Method and system for managing computer systems
US6032184A (en) * 1995-12-29 2000-02-29 Mci Worldcom, Inc. Integrated interface for Web based customer care and trouble management
US6138249A (en) * 1997-12-11 2000-10-24 Emc Corporation Method and apparatus for monitoring computer systems during manufacturing, testing and in the field
US6141507A (en) * 1998-07-10 2000-10-31 Ricoh Company, Ltd. Service system for image forming apparatuses
US20010047270A1 (en) * 2000-02-16 2001-11-29 Gusick David L. Customer service system and method
US6366919B2 (en) * 1999-03-23 2002-04-02 Lexent Inc. System for managing telecommunication sites
US20020091821A1 (en) * 2000-11-17 2002-07-11 Kojiro Katayama Information processing method for managing equipment, equipment managing program, recording medium storing equipment managing program, and equipment managing method
US20020123983A1 (en) * 2000-10-20 2002-09-05 Riley Karen E. Method for implementing service desk capability
US6493695B1 (en) * 1999-09-29 2002-12-10 Oracle Corporation Methods and systems for homogeneously routing and/or queueing call center customer interactions across media types
US6516055B1 (en) * 1999-12-29 2003-02-04 Bellsouth Intellectual Property Corp. Interface for trouble report input system and trouble report resolution system
US6587647B1 (en) * 2001-10-31 2003-07-01 Ricoh Co., Ltd. Method and system of remote monitoring of image forming apparatus
US6591296B1 (en) * 1999-12-15 2003-07-08 General Electric Company Remote notification of machine diagnostic information utilizing a unique email address identifying the sensor, the associated machine, and the associated machine condition
US6601190B1 (en) * 1999-10-28 2003-07-29 Hewlett-Packard Development Company, L.P. Automatic capture and reporting of computer configuration data
US6654915B1 (en) * 2000-09-11 2003-11-25 Unisys Corporation Automatic fault management system utilizing electronic service requests
US6697969B1 (en) * 1999-09-01 2004-02-24 International Business Machines Corporation Method, system, and program for diagnosing a computer in a network system
US6859783B2 (en) * 1995-12-29 2005-02-22 Worldcom, Inc. Integrated interface for web based customer care and trouble management
US6931105B2 (en) * 2002-08-19 2005-08-16 International Business Machines Corporation Correlating call data and speech recognition information in a telephony application

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6510203B1 (en) * 1999-10-20 2003-01-21 Qwest Communications International Inc. Central office technician notification and information system

Patent Citations (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5666481A (en) * 1993-02-26 1997-09-09 Cabletron Systems, Inc. Method and apparatus for resolving faults in communications networks
US5896440A (en) * 1994-05-26 1999-04-20 Gte Service Corporation System and method for providing a unified communications link between divergent communication networks
US5815652A (en) * 1995-05-31 1998-09-29 Hitachi, Ltd. Computer management system
US6859783B2 (en) * 1995-12-29 2005-02-22 Worldcom, Inc. Integrated interface for web based customer care and trouble management
US6032184A (en) * 1995-12-29 2000-02-29 Mci Worldcom, Inc. Integrated interface for Web based customer care and trouble management
US5854828A (en) * 1996-08-20 1998-12-29 Dell U.S.A., L.P. Telephone customer support utility
US6026500A (en) * 1997-05-13 2000-02-15 Electronic Data Systems Corporation Method and system for managing computer systems
US6138249A (en) * 1997-12-11 2000-10-24 Emc Corporation Method and apparatus for monitoring computer systems during manufacturing, testing and in the field
US6141507A (en) * 1998-07-10 2000-10-31 Ricoh Company, Ltd. Service system for image forming apparatuses
US6366919B2 (en) * 1999-03-23 2002-04-02 Lexent Inc. System for managing telecommunication sites
US6697969B1 (en) * 1999-09-01 2004-02-24 International Business Machines Corporation Method, system, and program for diagnosing a computer in a network system
US6493695B1 (en) * 1999-09-29 2002-12-10 Oracle Corporation Methods and systems for homogeneously routing and/or queueing call center customer interactions across media types
US6601190B1 (en) * 1999-10-28 2003-07-29 Hewlett-Packard Development Company, L.P. Automatic capture and reporting of computer configuration data
US6591296B1 (en) * 1999-12-15 2003-07-08 General Electric Company Remote notification of machine diagnostic information utilizing a unique email address identifying the sensor, the associated machine, and the associated machine condition
US6516055B1 (en) * 1999-12-29 2003-02-04 Bellsouth Intellectual Property Corp. Interface for trouble report input system and trouble report resolution system
US20010047270A1 (en) * 2000-02-16 2001-11-29 Gusick David L. Customer service system and method
US6654915B1 (en) * 2000-09-11 2003-11-25 Unisys Corporation Automatic fault management system utilizing electronic service requests
US20020123983A1 (en) * 2000-10-20 2002-09-05 Riley Karen E. Method for implementing service desk capability
US20020091821A1 (en) * 2000-11-17 2002-07-11 Kojiro Katayama Information processing method for managing equipment, equipment managing program, recording medium storing equipment managing program, and equipment managing method
US6587647B1 (en) * 2001-10-31 2003-07-01 Ricoh Co., Ltd. Method and system of remote monitoring of image forming apparatus
US6931105B2 (en) * 2002-08-19 2005-08-16 International Business Machines Corporation Correlating call data and speech recognition information in a telephony application

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030233441A1 (en) * 2002-05-08 2003-12-18 Yoko Nishiyama Information distribution system
US7403990B2 (en) * 2002-05-08 2008-07-22 Ricoh Company, Ltd. Information distribution system
US20050210161A1 (en) * 2004-03-16 2005-09-22 Jean-Pierre Guignard Computer device with mass storage peripheral (s) which is/are monitored during operation
US20070055725A1 (en) * 2005-09-07 2007-03-08 Gianluca Bernardini Method, system and computer program for providing web pages based on client state
US7668905B2 (en) * 2005-09-07 2010-02-23 International Business Machines Corporation Method, system and computer program for providing web pages based on client state
US20070266138A1 (en) * 2006-05-09 2007-11-15 Edward Spire Methods, systems and computer program products for managing execution of information technology (it) processes
US8504679B2 (en) * 2006-05-09 2013-08-06 Netlq Corporation Methods, systems and computer program products for managing execution of information technology (IT) processes
US20080126870A1 (en) * 2006-06-30 2008-05-29 Kabushiki Kaisha Toshiba Maintenance system, method of controlling maintenance system, server, record medium in which program used for server is recorded, computer and record medium in which program used for computer is recorded
US7747905B2 (en) * 2006-06-30 2010-06-29 Kabushiki Kaisha Toshiba Maintenance system, method of controlling maintenance system, server, record medium in which program used for server is recorded, computer and record medium in which program used for computer is recorded
US8055699B2 (en) * 2006-09-30 2011-11-08 Samsung Electronics Co., Ltd Apparatus and method for interfacing in a communication system
US20080082990A1 (en) * 2006-09-30 2008-04-03 Samsung Electronics Co., Ltd. Apparatus and method for interfacing in a communication system
US7624309B2 (en) * 2007-01-16 2009-11-24 Microsoft Corporation Automated client recovery and service ticketing
US20080172421A1 (en) * 2007-01-16 2008-07-17 Microsoft Corporation Automated client recovery and service ticketing
US7904752B2 (en) * 2008-06-03 2011-03-08 International Business Machines Corporation Synchronizing device error information among nodes
US20090300436A1 (en) * 2008-06-03 2009-12-03 International Business Machines Corporation Synchronizing device error information among nodes
US8115607B2 (en) 2008-09-10 2012-02-14 International Business Machines Corporation Microphone diagnostic inside system with voip alerting and monitoring
US20100060436A1 (en) * 2008-09-10 2010-03-11 International Business Machines Corporation Microphone diagnostic inside system with voip alerting and monitoring
US20120163194A1 (en) * 2009-08-28 2012-06-28 Telefonaktiebolaget Lm Ericsson(Publ) Handling Alarms Based On User Session Records
US8804492B2 (en) * 2009-08-28 2014-08-12 Telefonaktiebolaget L M Ericsson (Publ) Handling alarms based on user session records
US9306799B2 (en) 2012-03-19 2016-04-05 Ricoh Company, Limited Information processing apparatus, information processing method, and computer program product
US20130305102A1 (en) * 2012-05-11 2013-11-14 James Malnati Automated trouble ticket generation
US8892965B2 (en) * 2012-05-11 2014-11-18 Unisys Corporation Automated trouble ticket generation

Also Published As

Publication number Publication date Type
JP4185661B2 (en) 2008-11-26 grant
US20020073356A1 (en) 2002-06-13 application
US7017071B2 (en) 2006-03-21 grant
JP2002157357A (en) 2002-05-31 application

Similar Documents

Publication Publication Date Title
US6178442B1 (en) Electronic mail system and electronic mail access acknowledging method
US7375835B1 (en) E-mail transmission of print-ready documents
US6775023B1 (en) Center server, information processing apparatus and method, and print system
US5841981A (en) Network management system displaying static dependent relation information
US20040039811A1 (en) Management system for devices connecting with network
US6430601B1 (en) Mobile document paging service
US20030128991A1 (en) Integrated service data management system
US6477567B1 (en) Method for managing a status request transmitted from a managing device to an interface device through a network
US20020178243A1 (en) Apparatus and method for centrally managing network devices
US7058088B2 (en) Data communication program product to rewrite simultaneously firmware of plurality of devices connected to network
US20090190166A1 (en) Print processing system
US5696486A (en) Method and apparatus for policy-based alarm notification in a distributed network management environment
US6832250B1 (en) Usage-based billing and management system and method for printers and other assets
US6944659B2 (en) Method and apparatus for gathering and transmitting information for events relating to a networked appliance
US6373383B1 (en) Method and apparatus for policy-based alarm notification in a distributed network management environment
US20010034852A1 (en) Network management method for providing device list and network management device to provide device list
US6167448A (en) Management event notification system using event notification messages written using a markup language
US20030225894A1 (en) Image forming apparatus including web service functions
US20020080391A1 (en) Print control method, a print server, a client and a recording medium in a network environment
US20040130746A1 (en) Internet print protocol print dispatch server
US7325054B2 (en) System for notifying destination user when status of consumable products of printing devices meets user selected notification condition
US6970923B1 (en) Device management network system management server and computer readable medium
US20040073720A1 (en) Centralized monitoring and management of peripherals located at multiple sites
US20050097198A1 (en) Printer monitoring system and method
US6359974B1 (en) Communication records management device