JP2012203430A - Remote management device, remote management system, and remote management program - Google Patents

Remote management device, remote management system, and remote management program Download PDF

Info

Publication number
JP2012203430A
JP2012203430A JP2011064439A JP2011064439A JP2012203430A JP 2012203430 A JP2012203430 A JP 2012203430A JP 2011064439 A JP2011064439 A JP 2011064439A JP 2011064439 A JP2011064439 A JP 2011064439A JP 2012203430 A JP2012203430 A JP 2012203430A
Authority
JP
Japan
Prior art keywords
device
server
management
mediation
devices
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.)
Pending
Application number
JP2011064439A
Other languages
Japanese (ja)
Inventor
Mayu Kondo
麻由 近藤
Original Assignee
Ricoh Co Ltd
株式会社リコー
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
Application filed by Ricoh Co Ltd, 株式会社リコー filed Critical Ricoh Co Ltd
Priority to JP2011064439A priority Critical patent/JP2012203430A/en
Publication of JP2012203430A publication Critical patent/JP2012203430A/en
Application status is Pending legal-status Critical

Links

Images

Abstract

The processing of an intermediary system that mediates communication between a device and a center system that manages the device is reduced.
A center system manages devices via a first cloud mediation server, a second cloud mediation server, and a reception server for managed devices that do not have mediation devices or mediation device modules. The reception server transmits a report from the management target device to either the first cloud mediation server or the second cloud mediation server according to the contract form of the management target device. Each of the first cloud mediation server and the second cloud mediation server provides a service corresponding to the contract form to the management target device.
[Selection] Figure 1

Description

  The present invention relates to a remote management apparatus, a remote management system, and a remote management program for managing devices via a network.

  A device management mechanism in which an intermediary device is arranged in a user environment is already known. By arranging the intermediary device in the user environment, it is possible to collectively manage devices (for example, image forming apparatuses and multifunction peripherals) existing in the user environment. Also, a device management mechanism is already known in which a part of the function of the mediation device is mounted on a device in the user environment and communicates directly with the center system.

  FIG. 17 shows an example of a remote management system for equipment according to the prior art. The center system 500 has one or a plurality of management servers and is connected via the Internet 400, for example, the customer A device 601 and 602, each of which is an image forming apparatus or a multifunction device, and the customer B device. Remotely manage 603 and 604.

  At the customer A, the device 601 has a remote management device module 701 that is generally used in the remote management system, for example, which accepts remote management from the center system 500. The mediation device 600 includes a mediation device module 700, communicates with the center system 500 via the Internet 400, and mediates management of the device 601 by the center system 500.

  On the other hand, the device 602 includes an individual device management module 702 and an intermediary device module 703. The mediation device module 703 has a function equivalent to that of the mediation device module 700 described above. The individual device management module 702 performs management unique to the device 602 in response to communication with the center system 500 performed by the mediation device module 703 via the Internet 400.

  At customer B, the device 603 is a product of a manufacturer related to this remote management system, and the device 604 is a product of another manufacturer. These devices 60 3 and 604 include a wrapper 705 and a communication library (communication Lib) 706 by a remote management device SDK (Software Development Kit) 704 provided from the remote management system side. The wrapper 705 absorbs the difference in configuration between devices. The devices 603 and 604 communicate with the mediation system 502 using the wrapper 705 and the communication library 706, and are managed by the center system 500.

  The mediation system 502 includes a device management module 510 and, like the mediation device 600 described above, communicates with the center system 500 and mediates management of the devices B 603 and 604 of the customer B by the center system 500. The mediation system 502 includes a device management module 510 as software for that purpose.

  In such a remote management system, the center system 500 manages the devices 601 to 604 via the Internet 400 using the mediation device 600, the mediation device module 703, and the mediation system 502.

  Patent Document 1 discloses a technique in which a mediating apparatus that manages devices arranged in a user environment can communicate with a center system beyond a firewall.

  Here, in the above-described remote management system, when the number of devices connected to the Internet 400 and managed by the center system 500 increases, the load on the mediation system 502 increases, and problems such as processing delays may occur. . Therefore, a mechanism that can reduce the processing in the mediation system 502 is required.

  The present invention has been made in view of the above, and an object of the present invention is to reduce the processing of an intermediary system that mediates communication between a device and a center system that manages the device.

  In order to solve the above-described problems and achieve the object, the first invention provides a management means for remotely managing a device by communicating via a network, and the management means and the device via the network. Intermediary means that mediates communication and provides services corresponding to the contract form of the device, and accepts requests transmitted from a plurality of devices, and accepts distribution among the mediator means according to the contract form of the device Means.

  In addition, the second invention relates to a management means for remotely managing a device by performing communication via a network, and a notification transmitted from the device via the communication between the management means and the device via the network. An intermediary unit that provides a service corresponding to a type, and an accepting unit that accepts a report transmitted from a plurality of devices and distributes the report to a mediation unit according to the type of the report among the plurality of mediation units. .

  Further, the third invention mediates communication between the management server for remotely managing the device by performing communication via the network and the management server and the device via the network, and corresponds to the contract form of the device. It is characterized by comprising a mediation server that provides a service and a reception server that accepts requests transmitted from a plurality of devices and distributes the requests among the plurality of mediation servers to a mediation server according to the contract form of the device.

  The fourth aspect of the invention relates to a notification transmitted from a device through a communication between the management server that remotely manages the device by performing communication via the network, and the communication between the management server and the device via the network. A mediation server that provides a service corresponding to a type, and a reception server that receives a report transmitted from a plurality of devices and distributes the report to a mediation server according to the type of report among the plurality of mediation servers. .

  Further, the fifth aspect of the present invention mediates communication between the management step for remotely managing the device by performing communication via the network and the device by the management step via the network, and corresponds to the contract form of the device. An intermediary step for providing a service and an accepting step for accepting requests transmitted from a plurality of devices and distributing the intermediary steps according to the contract form of the device among the plurality of intermediary steps. .

  Further, the sixth aspect of the invention relates to a management step for remotely managing a device by performing communication via a network, and a notification transmitted from the device via the network communication between the device and the device according to the management step. An intermediary step for providing a service corresponding to a type and a computer for receiving a report transmitted from a plurality of devices and receiving a distribution step according to the type of report among the plurality of mediation steps. Features.

  According to the present invention, it is possible to reduce the processing of an intermediary system that mediates communication between a device and a center system that manages the device.

FIG. 1 is a schematic diagram schematically illustrating a remote management system applicable to the present embodiment. FIG. 2 is a functional block diagram illustrating an example of functions related to device management in the multifunction peripheral. FIG. 3 is a functional block diagram illustrating functions of an example of the reception server. FIG. 4A is a schematic diagram illustrating an example of a sorting table. FIG. 4B is a schematic diagram illustrating an example of a sorting table. FIG. 5 is a functional block diagram illustrating functions of an example of a distribution destination server. FIG. 6 is a schematic diagram illustrating a sequence of an example of a registration process related to the device installation. FIG. 7 is a flowchart illustrating an example of a reception server when a new device is installed. FIG. 8 is a schematic diagram illustrating an example of processing when a cloud mediation server is provided for each contract form. FIG. 9 is a flowchart showing an example of processing in the reception server when a call transmitted from a device is received when a cloud mediation server is provided for each contract form. FIG. 10 is a schematic diagram illustrating an example of processing when a cloud mediation server is provided for each service. FIG. 11 is a flowchart illustrating an example of processing in the lobby server when a call transmitted from a device is received when a cloud mediation server is provided for each service. FIG. 12 is a schematic diagram illustrating an example of processing in the case of determining whether or not the received notification is valid in the distribution destination server. FIG. 13 is a flowchart illustrating an example of a process for determining whether the notification received by the distribution destination server is valid. FIG. 14 is a schematic diagram illustrating an example of processing when the center system collects information from each device. FIG. 15 is a flowchart showing an example of processing in the cloud mediation server when the center system collects information. FIG. 16 is a flowchart showing an example of processing in the cloud mediation server when the center system collects information. FIG. 17 is a schematic diagram showing an example of a device remote management system according to the prior art.

  An embodiment of a remote management system according to the present invention will be described below in detail with reference to the accompanying drawings. FIG. 1 schematically shows a remote management system applicable to this embodiment. The center system 10 remotely manages the devices 30 and 31 of the customer A and the devices 32 and 33 of the customer B connected via the Internet 40. These devices 30 to 33 are assumed to be image forming apparatuses or multifunction devices that realize a printing function, a scanner function, a copying function, a FAX function, and the like in a single casing.

  The center system 10 further includes a first cloud mediation server 11, a second cloud mediation server 12, and a reception server 13. The center system 10, the first cloud mediation server 11, the second cloud mediation server 12, and the reception server 13 include a device management module 100 for managing the devices 30 to 33 as a whole.

  The first cloud mediation server 11 mediates management by the center system 10 according to the first type of maintenance contract (for example, performance contract). The second cloud mediation server 12 mediates management by the center system 10 based on the second type of maintenance contract (for example, annual contract). The reception server 13 receives requests for the center system 10 from the devices 32 and 33 and distributes the requests to the first cloud mediation server 11 and the second cloud mediation server 12. The reception server 13 receives a request from the center system 10 and distributes it to the devices 32 and 33.

  Each of the first cloud mediation server 11 and the second cloud mediation server 12 is composed of one or a plurality of management servers, and a plurality of computers connected to each other in a network cooperate with each other to provide services via the Internet. Cloud computing technology is used. According to the cloud computing technology, the service user does not need to be aware of the individual computers constituting the cloud.

  In the following description, it is assumed that the performance contract corresponds to a service call (SC), a toner order call (supply order call), and periodic part replacement. The annual contract corresponds to the SC, and it is possible to add periodic parts replacement as an option contract.

  Customer A has a plurality of devices 30 and 31 and an intermediary device 20. At the customer A, the device 30 accepts remote management from the center system 10 as software. For example, this remote management system has a general-purpose remote management device module 111. The mediation device 20 includes a mediation device module 110 as software, and communicates with the center system 10 via the Internet 40 to mediate management of the device 30 by the center system 10.

  On the other hand, the device 31 includes an individual device management module 112 and an intermediary device module 113 as software. The mediation device module 113 has the same function as the mediation device module 110 described above. The individual device management module 112 performs management specific to the device 31 in response to communication with the center system 10 performed by the mediation device module 113 via the Internet 40.

  Customer B has a plurality of devices 32 and 33. Of these, the device 32 is a product of a manufacturer related to the remote management system, and the device 33 is a product of another manufacturer. These devices 32 and 33 include, as software, a remote management device SDK (Software Development Kit) unit 120 provided from the remote management system side, a wrapper unit 122 formed by the remote management device SDK unit 120, and a communication library (communication Lib). ) Section 121, a security library (not shown), and setting data.

  The wrapper unit 122 is software for absorbing a difference in configuration between devices. The devices 32 and 33 of the customer B use the wrapper unit 122, the communication library unit 121, etc., and the center system via the first cloud mediation server 11, the second cloud mediation server 12, the reception server 13, etc. 10 to receive communication from the center system 10.

  In such a remote management system, the center system 10 uses the mediation device 20 or the mediation device module 113 to manage objects having the mediation device 20 or the mediation device module 113 such as the devices 30 and 31. Manage equipment. On the other hand, the center system 10 receives the first cloud mediation server 11, the second cloud mediation server 12, and the reception for management objects that do not have the mediation device 20 or the mediation device module 113, such as the devices 32 and 33. Device management is performed via the server 13.

  FIG. 2 is a functional block diagram illustrating an example of functions related to device management in the multifunction device 200. The configuration illustrated in FIG. 2 can be applied to the devices 32 and 33 described above. Functions related to device management of the MFP 200 can be broadly classified into a communication library unit 121, a remote management device SDK unit 120, a wrapper unit 122, and a platform unit 123. For example, by installing the remote management device SDK unit 120, which is a program, in the multi-function device 200, the functions of these units are formed on the main storage device of the multi-function device 200. And realized.

  The communication library unit 121 includes a communication library 201 and a security library 202. The remote management device SDK unit 120 includes a remote management device SDK 210, setting data 211, and an event management library 212. The wrapper unit 122 includes a platform-dependent absorption module 220. The platform unit 123 includes an SDK I / F (interface) 231 and a platform 230. The platform 230 depends on the model of the multifunction device 200 and the like.

  The remote management device SDK 210 communicates with the first cloud mediation server 11 and the second cloud mediation server 12 using the communication library 201, the security library 202, and the setting data 211. Notification data at the time of communication is acquired from the platform 230 by the platform dependent absorption module 220 via the SDK I / F 231. The platform dependent absorption module 220 absorbs a part depending on the platform 230. By mounting the platform-dependent absorption module 220, the communication library portion and the remote management device SDK portion can operate without depending on the configuration of the multifunction device 200.

  The notification data has a fixed part and a variable part. The fixed part includes parameters that must be implemented by the platform-dependent absorption module 220. On the other hand, the variable part can freely set the parameter name and its value in the platform dependent absorption module 220.

  The setting value and the event are set when communicating with the cloud mediation system. Not limited to this, the event managed by the setting data 211 and the event management library 212 can be freely set from the platform dependent absorption module 220. Further, the communication library 201 and the security library 202 can be replaced as necessary.

  FIG. 3 is a functional block diagram showing functions of an example of the reception server 13. The reception server 13 includes a device communication module 240, a distribution destination server communication client module 241, a distribution destination server communication server module 242, a distribution processing module 243, a distribution table 244, a device management module 245, and a security / authentication module. 246, Web UI 247, device management database (DB) 248, setting parameter 249, and scheduler 250.

  The device communication module 240 communicates with the devices 32 and 33 via the Internet 40. The security / authentication module 246 performs an authentication process on the devices 32 and 33 which are communication destinations during the communication. The device management DB 248 stores management information of the devices 32 and 33 that are management targets. The setting parameter 249 is a setting parameter when communicating with the devices 32 and 33 that are communication destinations. The scheduler 250 manages a schedule of communication with the devices 32 and 33.

  The device management module 245 uses the device communication module 240, the security / authentication module 246, and the setting parameter 249 to communicate with the remote management device SDK unit 120 of the device 32 and the device 33, and from the device 32 and the device 33. Notification is received, information on the device 32 and the device 33 is acquired, and a command is transmitted to the device 32 and the device 33.

  Information on the devices 32 and 33 that perform communication is held in the device management DB 248. Information held in the device management DB 248 is notified to the center system 10 using the distribution destination server communication client module 241. At this time, the distribution processing module 243 distributes the notification to the distribution destination server in accordance with the information held in the distribution table 244. Further, the distribution destination server communication server module 242 responds according to a request from the distribution destination server. At this time, the distribution processing module 243 distributes the response transmission destination to the devices 32 and 33 in accordance with the information held in the distribution table 244. Information held in the device management DB 248 can be browsed using the Web UI 247.

  4A and 4B illustrate an example of the sorting table 244. FIG. 4A shows an example of the sorting table 244 when sorting is performed based on the contract form. In the figure, MFP ID is identification information of devices to be managed such as devices 32 and 33. In the example of FIG. 4A, a notification destination server is set for each contract form (performance contract, annual maintenance contract, and spot contract). FIG. 4B illustrates an example of the sorting table 244 when sorting is performed based on the type of report from the device. In the example of FIG. 4B, a notification destination server is set for each notification type such as an SC (service call), a toner ordering call, and a fixing unit replacement timing call.

  Each function of the reception server 13 is realized by, for example, installing a predetermined program in the reception server 13 and forming a module that executes each function on the main storage device of the reception server 13.

  FIG. 5 is a functional block diagram illustrating functions of an example of the distribution destination server described above. The distribution destination server 50 is, for example, the first cloud mediation server 11 and the second cloud mediation server 12 in FIG. The distribution destination server 50 includes a device communication module 260, a center communication client module 261, a center communication server module 262, a reception server communication client module 263, a reception server communication server module 264, a device management module 265, a security / authentication module 266, a Web UI 267, A device management DB 268, a setting parameter 269, and a scheduler 270 are included.

  The device communication module 260 communicates with the devices 32 and 33 via the Internet 40. The security / authentication module 266 performs an authentication process on the devices 32 and 33 which are communication destinations during the communication. The device management DB 268 stores management information of the devices 32 and 33 that are the management targets. The setting parameter 269 is a setting parameter when communicating with the devices 32 and 33. The scheduler 270 manages a communication schedule.

  The center communication client module 261 and the center communication server module 262 communicate with the center system 10. The reception server communication client module 263 receives the notification from the reception server 13. The reception server communication server module 264 transmits a notification to the reception server 13.

  The device management module 265 uses the device communication module 260, the security / authentication module 266, and the setting parameter 269 to communicate with the remote management device SDK unit 120 of the device 32 and the device 33. Notification is received, information on the device 32 and the device 33 is acquired, and a command is transmitted to the device 32 and the device 33.

  Information on the device 32 and the device 33 is held in the device management DB 268. Information held in the device management DB 268 is notified to the center system 10 using the center communication client module 261. Information held in the device management DB 268 can be browsed using the Web UI 267.

  Each function of the distribution destination server 50 is realized by, for example, installing a predetermined program in the reception server 13 and forming a module that executes each function on the main storage device of the distribution destination server 50. .

  In the remote management system according to the present embodiment, when a new device is installed at a customer, it is necessary to register information on the installed device in the center system 10. FIG. 6 shows a sequence of an example of a registration process related to this device installation. When the device MFP # 1 is newly installed at the customer with the maintenance contract as the performance contract, the remote management device SDK unit 120 is installed in the device MFP # 1, and this is received together with the maintenance contract information. The server 13 is notified (SEQ10). Upon receipt of this notification, the reception server 13 notifies the center system 10 that the device MFP # 1 has been installed (SEQ11). At the same time, the reception server 13 registers the identification information of the device MFP # 1, the contract form (performance contract), and information of the notification destination server set in advance for the contract form in the distribution table 244. To do.

  The same applies to other maintenance contracts. That is, when the device MFP # 2 is newly installed with the maintenance contract as an annual contract, the remote management device SDK unit 120 is installed in the device MFP # 2, and this is indicated together with the maintenance contract information in the reception server 13. (SEQ20). Upon receipt of this notification, the reception server 13 notifies the center system 10 that the device MFP # 2 has been installed (SEQ21). At the same time, the identification information of the device MFP # 2, the contract form (annual contract), and the information of the notification destination server preset for the contract form are registered in the distribution table 244.

  FIG. 7 is a flowchart showing an example of processing of the reception server 13 when the new device is installed in FIG. In step S100, an installation notification of the remote management device SDK unit 120 is waited for. If the installation notification is received, the process proceeds to step S101, and the management information of the device in which the remote management device SDK unit 120 is installed is added to the distribution table 244. In the next step S102, the center system 10 is notified that a new device has been installed.

  FIG. 8 shows an example of processing when a cloud mediation server is provided for each contract form. In this case, the reception server 13 uses the distribution table 244 shown in FIG. 4A when distributing based on the contract form. Here, the case where the device side operates as a client is shown. Further, it is assumed that a performance contract is made for device MFP # 1 and an annual contract is made for device MFP # 2 as maintenance contracts at customer MFPs MFP # 1 and MFP # 2.

  As a first example, a case where an SC occurs in device MFP # 1 will be described. The SC generated in device MFP # 1 is received by acceptance server 13 via Internet 40 (SEQ100). Receiving server 13 receives this SC, refers to distribution table 244, obtains the contract form from the identification information of device MFP # 1, and obtains a notification destination server corresponding to the obtained contract form. In this example, the contract form is assumed to be a performance contract based on the identification information of the device MFP # 1, and the first cloud mediation server 11 corresponding to the performance contract is determined as the notification destination server.

  Reception server 13 transmits the SC received from device MFP # 1 to first cloud mediation server 11 (SEQ101). The first cloud mediation server 11 transmits the received SC to the center system 10 (SEQ102). When the center system 10 receives the SC, the center system 10 performs necessary processing such as arranging service personnel according to the contents of the SC.

  As a second example, a case where a toner order call occurs in device MFP # 1 will be described. The toner order call generated in device MFP # 1 is received by reception server 13 via Internet 40 (SEQ110). Receiving server 13 receives this toner ordering call, refers to distribution table 244, obtains a contract form from the identification information of device MFP # 1, and obtains a notification destination server corresponding to the obtained contract form. In this example, it is assumed that the contract form of the device MFP # 1 is a performance contract, and the first cloud mediation server 11 corresponding to the performance contract is determined as the notification destination server.

  The receiving server 13 transmits the toner order call received from the device MFP # 1 to the first cloud mediation server 11 (SEQ111). The first cloud mediation server 11 transmits the received toner order call to the center system 10 (SEQ112). For example, the center system 10 executes a toner ordering process for the device MFP # 1 in response to the received toner ordering call.

  As a third example, a case where an SC occurs in device MFP # 2 will be described. The SC generated in device MFP # 2 is received by acceptance server 13 via Internet 40 (SEQ120). Receiving server 13 receives this SC, refers to distribution table 244, obtains the contract form from the identification information of device MFP # 2, and obtains the notification destination server corresponding to the obtained contract form. In this example, the contract form is assumed to be an annual contract based on the identification information of the device MFP # 2, and the second cloud mediation server 12 corresponding to the annual contract is determined as the notification destination server.

  Reception server 13 transmits the SC received from device MFP # 2 to second cloud mediation server 12 (SEQ121). The second cloud mediation server 12 transmits the received SC to the center system 10 (SEQ122). When the center system 10 receives the SC, the center system 10 performs necessary processing such as arranging service personnel according to the contents of the SC.

  As a fourth example, a case will be described in which a toner order call is generated in device MFP # 2. The toner ordering call generated in device MFP # 2 is received by reception server 13 via Internet 40 (SEQ130). Receiving server 13 receives this toner order call, refers to distribution table 244, obtains a contract form from the identification information of device MFP # 2, and obtains a notification destination server corresponding to the obtained contract form. In this example, the contract form is assumed to be an annual contract based on the identification information of the device MFP # 2, and the second cloud mediation server 12 corresponding to the annual contract is determined as the notification destination server.

  Reception server 13 transmits the toner order call received from device MFP # 2 to second cloud mediation server 12 (SEQ131). When the second cloud mediation server 12 refers to the device management DB 268 and confirms that the maintenance contract at the transmission source of the received toner ordering call is an annual contract, the second cloud mediation server 12 determines that the toner ordering process is not covered by the contract, Notification to the center system 10 is not performed.

  FIG. 9 is a flowchart showing an example of processing in the reception server 13 when a call related to a maintenance contract transmitted from a device installed at a customer is received when a cloud mediation server is provided for each contract form. It is. When the reception server 13 receives a call from a device installed at a customer, in step S110, the reception server 13 refers to information indicating a contract form included in the notification information notified by the call. Then, in the next step S111, the distribution table 244 is referred to based on the information indicating the contract form, and the notification destination server is determined.

  That is, if the information indicating the contract form indicates a performance contract, the process proceeds to step S112, and the call received from the device is notified to the performance contract server (for example, the first cloud mediation server 11 in FIG. 1). To do. If the information indicating the contract form indicates an annual contract, the process proceeds to step S113, and the call received from the device is notified to the annual contract server (for example, the second cloud mediation server 12 in FIG. 1). To do. Furthermore, if the information indicating the contract form indicates a spot contract, the process proceeds to step S114, and the call received from the device is notified to the spot contract server.

  FIG. 10 shows an example of processing when a cloud mediation server is provided for each service (call type). In this case, the reception server 13 uses the distribution table 244 shown in FIG. 4B when the distribution is performed based on the report type from the device.

  Here, a case where the device side operates as a client is shown. In the customer devices MFP # 1 and MFP # 2, a performance contract is maintained for the device MFP # 1 and an annual contract is maintained for the device MFP # 2. It is assumed that it is exchanged as a contract. Further, it is assumed that the first cloud mediation server 11 in FIG. 1 corresponds to the SC and the second cloud mediation server 12 corresponds to the toner order call. Furthermore, it is assumed that the lobby server 13 'has a configuration equivalent to that of the reception server 13 described above.

  As a first example, a case where an SC occurs in device MFP # 1 will be described. The SC generated in the device MFP # 1 is received by the lobby server 13 'via the Internet 40 (SEQ200). When the lobby server 13 ′ receives this SC, the lobby server 13 ′ refers to the distribution table 244 and obtains a notification destination server corresponding to the SC. In this example, the first cloud mediation server 11 corresponding to the SC is determined as the notification destination server.

  The lobby server 13 'transmits the SC received from the device MFP # 1 to the first cloud mediation server 11 (SEQ201). The first cloud mediation server 11 transmits the received SC to the center system 10 (SEQ202). When the center system 10 receives the SC, the center system 10 performs necessary processing such as arranging service personnel according to the contents of the SC.

  As a second example, a case where a toner order call occurs in device MFP # 1 will be described. The toner ordering call generated by device MFP # 1 is received by lobby server 13 'via Internet 40 (SEQ210). When the lobby server 13 'receives the toner order call, the lobby server 13' refers to the sorting table 244 to obtain a notification destination server corresponding to the toner order call. In this example, the second cloud mediation server 12 corresponding to the toner order call is determined as the notification destination server.

  The lobby server 13 'transmits the toner order call received from the device MFP # 1 to the second cloud mediation server 12 (SEQ211). The second cloud mediation server 12 transmits the received toner order call to the center system 10 (SEQ212). For example, the center system 10 executes a toner ordering process for the device MFP # 1 in response to the received toner ordering call.

  As a third example, a case where an SC occurs in device MFP # 2 will be described. The SC generated in the device MFP # 2 is received by the lobby server 13 'via the Internet 40 (SEQ220). When the lobby server 13 ′ receives this SC, the lobby server 13 ′ refers to the distribution table 244 and obtains a notification destination server corresponding to the SC. In this example, the first cloud mediation server 11 corresponding to the SC is determined as the notification destination server.

  The lobby server 13 'transmits the SC received from the device MFP # 2 to the first cloud mediation server 11 (SEQ221). The first cloud mediation server 11 transmits the received SC to the center system 10 (SEQ222). When the center system 10 receives the SC, the center system 10 performs necessary processing such as arranging service personnel according to the contents of the SC.

  As a fourth example, a case will be described in which a toner order call is generated in device MFP # 2. The toner ordering call generated in the device MFP # 2 is received by the lobby server 13 'via the Internet 40 (SEQ230). When the lobby server 13 'receives the toner order call, the lobby server 13' refers to the sorting table 244 to obtain a notification destination server corresponding to the toner order call. In this example, the second cloud mediation server 12 corresponding to the toner order call is determined as the notification destination server.

  The lobby server 13 'transmits the toner order call received from the device MFP # 2 to the second cloud mediation server 12 (SEQ231). When the second cloud mediation server 12 refers to the device management DB 268 and confirms that the maintenance contract at the transmission source of the received toner ordering call is an annual contract, the second cloud mediation server 12 determines that the toner ordering process is not covered by the contract, Notification to the center system 10 is not performed.

  FIG. 11 is a flowchart showing an example of processing in the lobby server 13 ′ when a call related to a maintenance contract transmitted from a device installed in a customer is received when a cloud mediation server is provided for each service. It is. When the lobby server 13 ′ receives a call from a device installed at a customer, the lobby server 13 ′ refers to information indicating a report type included in the notification information notified by the call in step S <b> 120. Then, in the next step S121, the distribution table 244 is referred to based on the information indicating the report type, and the notification destination server is determined.

  That is, if the information indicating the report type indicates SC, the process proceeds to step S122, and the call received from the device is notified to the repair request server (for example, the first cloud mediation server 11 in FIG. 1). . If the information indicating the notification type indicates a toner order call, the process proceeds to step S123, and the call received from the device is changed to a toner order call reception server (for example, the second cloud mediation server 12 in FIG. 1). ). Furthermore, if the information indicating the notification type indicates the fixing unit replacement time, the process proceeds to step S124, and the call received from the device is notified to the periodic parts replacement server.

  FIG. 12 shows an example of processing in the distribution destination server 50 when it is determined whether or not the received notification is valid. Assume that the customer's device MFP has, for example, a maintenance contract with an annual contract. Further, it is assumed that the device MFP has an option contract for periodic parts replacement. Information regarding these contracts is registered in the device management DB 268 of the distribution destination server 50 for each contracted device.

  As a first example, a case where an SC occurs in device MFP will be described. In this case, the SC is notified from the device MFP to the lobby server 13 '(SEQ300). When the lobby server 13 'receives this SC, the lobby server 13' refers to the distribution table 244, obtains a contract form from the identification information of the device MFP, and obtains a notification destination server corresponding to the obtained contract form. In this example, based on the identification information of the device MFP, the contract form is an annual contract, and the second cloud mediation server 12 that is the distribution destination server 50 corresponding to the annual contract is determined as the notification destination server.

  The lobby server 13 'transmits the SC received from the device MFP to the second cloud mediation server 12 (SEQ301). The second cloud mediation server 12 transmits the received SC to the center system 10 (SEQ302).

  As a second example, a case will be described in which a toner order call occurs in the device MFP. In this case, the toner order call is notified from the device MFP to the lobby server 13 '(SEQ310). Upon receiving this toner order call, the lobby server 13 ′ refers to the distribution table 244, obtains a contract form from the identification information of the device MFP, and obtains a notification destination server corresponding to the obtained contract form. In this example, based on the identification information of the device MFP, the contract form is an annual contract, and the second cloud mediation server 12 that is the distribution destination server 50 corresponding to the annual contract is determined as the notification destination server.

  The lobby server 13 'transmits the toner order call received from the device MFP to the second cloud mediation server 12 (SEQ311). When the second cloud mediation server 12 refers to the device management DB 268 and confirms that the maintenance contract at the transmission source of the received toner ordering call is an annual contract, the second cloud mediation server 12 determines that the toner ordering process is not covered by the contract, Notification to the center system 10 is not performed.

  As a third example, a case will be described in which the replacement time of the fixing unit, which is a periodic replacement part, is approaching in the device MFP. In this case, the device MFP notifies the lobby server 13 'that it is almost time to replace the fixing unit (SEQ320). Upon receiving this notification, the lobby server 13 ′ refers to the distribution table 244, obtains a contract form from the identification information of the device MFP, and obtains a notification destination server corresponding to the obtained contract form. In this example, based on the identification information of the device MFP, the contract form is an annual contract, and the second cloud mediation server 12 that is the distribution destination server 50 corresponding to the annual contract is determined as the notification destination server.

  The lobby server 13 'transmits the notification received from the device MFP to the second cloud mediation server 12 (SEQ321). When the second cloud mediation server 12 refers to the device management DB 268 and confirms that the option contract for periodic parts replacement has been made in the maintenance contract of the received notification source, The MFP notifies that the time for replacement of the fixing unit is approaching (SEQ322). The center system 10 performs, for example, fixing unit ordering processing according to the contract contents of the device MFP.

  FIG. 13 is a flowchart illustrating an example of processing for determining whether or not the notification received by the distribution destination server 50 is valid. Here, it is assumed that an annual contract and an option contract for periodic replacement parts replacement have been made for the notification source device. When the distribution destination server 50 receives the notification from the lobby server 13 ′, first, the device management DB 268 is referred to and the form of the maintenance contract with which the transmission source device of the received notification is contracted is confirmed. In step S130, it is determined whether or not the type of the received notification is SC.

  If it is determined to be an SC, the process proceeds to step S131, the received SC is transmitted to the center system 10, and the SC is notified. On the other hand, if it is determined that the received notification type is not SC, the process proceeds to step S132 to determine whether the notification type is a toner order call. If it is determined that the call is a toner order call, the center system 10 is not notified that the toner order is not subject to the contract based on the contract form of the notification source device.

  On the other hand, if it is determined in step S132 that the notification type is not a toner ordering call, the process proceeds to step S133, and if it is determined that the notification type is a notification that the replacement timing of the fixing unit is approaching, the process is stepped. The process proceeds to S134. In step S134, it is determined whether or not an option contract for periodic replacement parts is exchanged based on the contract form of the notification source device. If it is determined that they have exchanged, the process proceeds to step S135, and the notification source device notifies the center system 10 that the time for replacement of the fixing unit is approaching.

  On the other hand, if it is determined in step S134 that an optional contract for periodic replacement parts has not been exchanged for the notification source device, notification to the center system 10 is not performed. Also, if it is determined in step S133 described above that the notification type is not a notification that the time for replacement of the fixing unit is approaching, the notification to the center system 10 is not performed. In addition, when another contract exists, those confirmation processes are also performed.

  FIG. 14 shows an example of processing when the center system 10 collects information from each of the devices MFP # 1 and MFP # 2. In this example, a distribution destination server 50 is provided for each contract form, and the receiving server 13 uses the distribution table 244 shown in FIG. 4A when performing distribution based on the contract form. Here, the case where the device side operates as a server is shown. In the customer MFPs MFP # 1 and MFP # 2, a performance contract is made as a maintenance contract for the device MFP # 1, and the device MFP # 2 has an annual contract. It is assumed that a contract and an option contract for periodic replacement parts are made. Further, it is assumed that the first cloud mediation server 11 in FIG. 1 corresponds to the performance contract, and the second cloud mediation server 12 corresponds to the annual contract.

  First, an information collection process for device MFP # 1 will be described. Center system 10 requests reception server 13 to collect report information of device MFP # 1 (SEQ400). Receiving server 13 refers to distribution table 244 and acquires the contract form of device MFP # 1 and the information of the notification destination server. In this case, the contract form is a performance contract, and the notification destination server is the first cloud mediation server 11. The reception server 13 requests the first cloud mediation server 11 to collect report information of the device MFP # 1 according to the acquired information (SEQ401).

  Upon receiving this request, the first cloud mediation server 11 transmits an abnormal state acquisition request to the device MFP # 1 (SEQ402). In response to this request, the abnormal state acquisition response transmitted from the device MFP # 1 is received by the first cloud mediation server 11 (SEQ403). This abnormal state acquisition response corresponds to the SC. Subsequently, the first cloud mediation server 11 transmits a supply status acquisition request to the device MFP # 1 (SEQ404).

  The supply status acquisition response transmitted from the device MFP # 1 in response to this request is received by the first cloud mediation server 11 (SEQ405). This supply status acquisition response corresponds to a toner order call. The first cloud mediation server 11 collects the abnormal state acquisition response received in SEQ 403 and the supply state acquisition response received in SEQ 405 as a report information collection response of the device MFP # 1 to the center system 10. Transmit (SEQ406).

  Further, the center system 10 requests the reception server 13 to collect a counter of the device MFP # 1 (SEQ407). The count value collected by the counter collection is a value indicating the number of times the fixing unit that is a regular replacement part is used. When this value exceeds a predetermined value, it is assumed that the fixing unit replacement time is approaching. The reception server 13 requests the first cloud mediation server 11 to acquire the count value of the device MFP # 1 (SEQ408).

  Upon receiving this request, the first cloud mediation server 11 transmits a counter acquisition request to the device MFP # 1 (SEQ409). The count value transmitted from the device MFP # 1 in response to this request is received by the first cloud mediation server 11 (SEQ410). The first cloud mediation server 11 transmits the received count value to the center system 10 as a counter collection response of the device MFP # 1 (SEQ411).

  Next, information collection processing for device MFP # 2 will be described. Center system 10 requests reception server 13 to collect report information of device MFP # 2 (SEQ420). Receiving server 13 refers to distribution table 244 and acquires the contract form of device MFP # 2 and the information of the notification destination server. In this case, the contract form is an annual contract, and the notification destination server is the second cloud mediation server 12. In accordance with the acquired information, reception server 13 requests second cloud mediation server 12 to perform scheduled collection of report information on device MFP # 2 (SEQ421).

  Receiving this request, second cloud mediation server 12 transmits an abnormal state acquisition request to device MFP # 2 (SEQ422). In response to this request, the abnormal state acquisition response transmitted from the device MFP # 2 is received by the second cloud mediation server 12 (SEQ423). This abnormal state acquisition response corresponds to the SC. Here, the device MFP # 2 does not transmit a supply status acquisition request because the contract form is an annual contract. The second cloud mediation server 12 transmits the abnormal state acquisition response received in SEQ423 to the center system 10 as a report information collection response of the device MFP # 2 (SEQ424).

  Furthermore, the center system 10 requests the reception server 13 to collect a counter for the device MFP # 2 (SEQ425). The reception server 13 requests the second cloud mediation server 12 to acquire the count value of the device MFP # 2 (SEQ426).

  Receiving this request, second cloud mediation server 12 transmits a counter acquisition request to device MFP # 2 (SEQ427). In response to this request, the count value transmitted from device MFP # 2 is received by second cloud mediation server 12 (SEQ428). Device MFP # 2 has an optional contract for periodic replacement parts. Therefore, the second cloud mediation server 12 transmits the received count value to the center system 10 as a counter collection response of the device MFP # 2 (SEQ429).

  FIG. 15 is a flowchart showing an example of processing in the first cloud mediation server 11 when the center system 10 collects information. In step S <b> 140, the first cloud mediation server 11 waits for reception of a request from the reception server 13. When a request is received from the reception server 13, the contents of the request are determined in steps S141 and S146. In step S141, the first cloud mediation server 11 determines whether the request from the reception server 13 is a report information collection request. If it is determined that the request is a report information collection request, the process proceeds to step S142.

  In step S142, first cloud mediation server 11 transmits an abnormal state acquisition request to device MFP # 1 in accordance with the received request. Note that information indicating the transmission destination of this request is included in the request from the reception server 13, for example. In the next step S143, the first cloud mediation server 11 waits to receive a response from the device MFP # 1. If the response is received, a supply status acquisition request is transmitted to device MFP # 1 in step S144. In the next step S145, reception of a response from device MFP # 1 is awaited. If a response is received, the series of processes is terminated, and the information received in steps S143 and S145 is collected and transmitted to the center system 10 as a report information collection response of the device MFP # 1.

  If it is determined in step S141 described above that the request from the reception server 13 is not a report information collection request, the process proceeds to step S146, and it is determined whether or not the request is a counter information collection request. If it is determined that the request is not a counter information collection request, a series of processing is terminated without doing anything.

  On the other hand, if it is determined in step S146 that the request from reception server 13 is a counter information collection request, the process proceeds to step S147, and a counter information acquisition request is transmitted to device MFP # 1. Then, in the next step S148, reception of a response from device MFP # 1 is awaited. If a response is received, the series of processing is terminated, and the received counter information is transmitted to the center system 10 as a counter collection response.

  FIG. 16 is a flowchart showing an example of processing in the second cloud mediation server 12 when the center system 10 collects information. In step S150, the second cloud mediation server 12 waits for reception of a request from the reception server 13. When a request is received from the reception server 13, the contents of the request are determined in steps S151 and S154. In step S151, the second cloud mediation server 12 determines whether the request from the reception server 13 is a report information collection request. If it is determined that the request is a report information collection request, the process proceeds to step S152.

  In step S152, second cloud mediation server 12 transmits an abnormal state acquisition request to device MFP # 2 in accordance with the received request. Note that information indicating the transmission destination of this request is included in the request from the reception server 13, for example. In the next step S153, the second cloud mediation server 12 waits for reception of a response from the device MFP # 2. When the response is received, the series of processes is terminated, and the received abnormal state acquisition response is transmitted to the center system 10 as a report information collection response of the device MFP # 2. Since the second cloud mediation server 12 provides an annual contract service, it does not make a supply status acquisition request that is not subject to contract.

  If it is determined in step S151 described above that the request from the reception server 13 is not a report information collection request, the process proceeds to step S154, and it is determined whether or not the request is a counter information collection request. If it is determined that the request is not a counter information collection request, a series of processing is terminated without doing anything.

  On the other hand, if it is determined in step S154 that the request from reception server 13 is a counter information collection request, the process proceeds to step S155, and a counter information acquisition request is transmitted to device MFP # 2. In next step S156, reception of a response from device MFP # 2 is waited. If a response is received, the series of processing is terminated, and the received counter information is transmitted to the center system 10 as a counter collection response.

  As described above, according to the embodiment of the present invention, servers that provide services to devices are divided according to the contract form of the customer's device or the type of report transmitted from the device. Therefore, it is possible to reduce the load on the server that provides the service when the number of devices to be managed increases.

10 center system 11 first cloud mediation server 12 second cloud mediation server 13 reception server 20 mediation device 30, 31, 32, 33 device 40 internet 100 device management module 110 mediation device module 111 remote management device module 112 individual device management Module 113 Mediation device module 120 Remote management device SDK unit 121 Communication library unit 122 Wrapper unit 200 Multifunction device 210 Remote management device SDK
220 Platform-dependent absorption module 241 Distribution server communication client module 242 Distribution server communication server module 243 Distribution processing module 244 Distribution tables 248 and 268 Device management DB
263 Reception server communication client module 264 Reception server communication server module

JP 2003-323360 A

Claims (7)

  1. Management means for remotely managing devices by communicating via a network;
    Mediating means for mediating the communication between the management means and the device via the network and providing a service corresponding to a contract form of the device;
    A remote management apparatus comprising: a receiving unit that receives requests transmitted from a plurality of the devices and distributes the requests among the plurality of mediating units to a mediating unit according to the contract form of the device.
  2. The accepting means further includes:
    The remote management apparatus according to claim 1, wherein a request for the device is received from the management unit, and the request is distributed to a mediation unit according to the contract form of the device among the plurality of mediation units.
  3. Management means for remotely managing devices by communicating via a network;
    Mediating means for mediating the communication between the management means and the device via the network and providing a service corresponding to the type of report transmitted from the device;
    A remote management device comprising: a receiving unit that receives the notification transmitted from a plurality of the devices and distributes the notification to a mediating unit corresponding to a type of the notification among the plurality of mediating units.
  4. A management server that remotely manages devices by communicating via a network; and
    An intermediary server that mediates the communication between the management server and the device via the network and provides a service corresponding to a contract form of the device;
    A remote management system comprising: an accepting server that accepts requests transmitted from a plurality of the devices and distributes among the plurality of mediation servers to a mediation server according to the contract form of the device.
  5. A management server that remotely manages devices by communicating via a network; and
    An intermediary server that mediates the communication between the management server and the device via the network and provides a service corresponding to a type of report transmitted from the device;
    A remote management system comprising: a reception server that receives the notification transmitted from a plurality of the devices and distributes the notification to a mediation server according to the type of the notification among the plurality of mediation servers.
  6. A management step for remotely managing devices by communicating via a network;
    An intermediary step of mediating the communication with the device by the management step via the network and providing a service corresponding to a contract form of the device;
    A remote management program for receiving a request transmitted from a plurality of the devices and causing a computer to execute a reception step of distributing a plurality of mediation steps to a mediation step according to the contract form of the device.
  7. A management step for remotely managing devices by communicating via a network;
    An intermediary step of mediating the communication with the device by the management step via the network and providing a service corresponding to a type of report transmitted from the device;
    A remote management program for receiving a report transmitted from a plurality of the devices and causing a computer to execute a reception step of distributing the distribution step according to the type of notification among the plurality of mediation steps.
JP2011064439A 2011-03-23 2011-03-23 Remote management device, remote management system, and remote management program Pending JP2012203430A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011064439A JP2012203430A (en) 2011-03-23 2011-03-23 Remote management device, remote management system, and remote management program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011064439A JP2012203430A (en) 2011-03-23 2011-03-23 Remote management device, remote management system, and remote management program

Publications (1)

Publication Number Publication Date
JP2012203430A true JP2012203430A (en) 2012-10-22

Family

ID=47184430

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011064439A Pending JP2012203430A (en) 2011-03-23 2011-03-23 Remote management device, remote management system, and remote management program

Country Status (1)

Country Link
JP (1) JP2012203430A (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1196099A (en) * 1997-09-19 1999-04-09 Hitachi Ltd Service providing system
JP2003167810A (en) * 2001-11-30 2003-06-13 Nippon Telegr & Teleph Corp <Ntt> Server selecting method, device and program, and recording medium
JP2006106859A (en) * 2004-09-30 2006-04-20 Toshiba Corp Resource allocation device and resource allocation method for use with information processing system
JP2011015196A (en) * 2009-07-02 2011-01-20 Hitachi Ltd Load assignment control method and load distribution system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1196099A (en) * 1997-09-19 1999-04-09 Hitachi Ltd Service providing system
JP2003167810A (en) * 2001-11-30 2003-06-13 Nippon Telegr & Teleph Corp <Ntt> Server selecting method, device and program, and recording medium
JP2006106859A (en) * 2004-09-30 2006-04-20 Toshiba Corp Resource allocation device and resource allocation method for use with information processing system
JP2011015196A (en) * 2009-07-02 2011-01-20 Hitachi Ltd Load assignment control method and load distribution system

Similar Documents

Publication Publication Date Title
US7565656B2 (en) System, method and program for allocating computer resources
US8255529B2 (en) Methods and systems for providing deployment architectures in cloud computing environments
CN103281344B (en) For integrated metrology hybrid cloud service usage methods and systems
US10033832B2 (en) Systems and methods for providing a client agent for delivery of remote services
US6757730B1 (en) Method, apparatus and articles-of-manufacture for network-based distributed computing
EP2510653B1 (en) Cloud computing monitoring and management system
EP1768044A2 (en) Security vulnerability information aggregation
US9594597B2 (en) Systems and methods for automated server side brokering of a connection to a remote device
US10122798B2 (en) System and process for managing network communications
US9110976B2 (en) Supporting compliance in a cloud environment
RU2378689C2 (en) Network control system and method
US20120265865A1 (en) Device management system
CN1874283B (en) Centralized monitoring system and method for controlling the same
JP2004139572A (en) Remote management system, its mediation device, software update method, and program
JP2004531802A (en) Service management and / or service support and / or methods and systems for service report generation
JP2008527514A (en) How to promote a comprehensive grid environment management by monitoring and distribution of grid activity, system, and computer program
KR20060049893A (en) Device management system and device management command scheduling method thereof
KR101891506B1 (en) Methods and systems for portably deploying applications on one or more cloud systems
US7979515B2 (en) Distribution management method, a distribution management system and a distribution management server
KR101805820B1 (en) Social Network System with Access Provision Mechanism and Method of Operation thereof
JP5509754B2 (en) Software management apparatus, software distribution system, installation method and program
JP2011048812A (en) System and apparatus for processing image, image forming apparatus, image processing method, program, and recording medium
KR20130002940A (en) Pull-print system, print job management method, print server, control method therefor and computer-readable medium
JP5539129B2 (en) Image forming apparatus, firmware update method, and program
Rahman et al. A taxonomy and survey on autonomic management of applications in grid computing environments

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140214

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140926

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20141104

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150105

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20150901