JP2017076952A - Apparatus management device, apparatus management system, apparatus management method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make it possible to handle apparatuses regarded as the same through cognitive identification as the same ones to reduce time and effort for management.SOLUTION: An apparatus management device 10 comprises: a mapping management part 15 that issues a mapping ID for managing an apparatus 20 and generates mapping information in which an apparatus ID identifying a solid body of the apparatus 20 is associated with the mapping ID; and an apparatus validity management part 14 that generates validity management information in which validity indicating validity or invalidity of the apparatus 20 is associated with the apparatus ID. In response to the apparatus validity management part 14 generating validity management information indicating invalidity of a first apparatus and generating validity management information indicating validity of a second apparatus that is handled as the same apparatus as the first apparatus, the mapping management part 15 generates mapping information in which a mapping ID associated with an apparatus ID of the first apparatus is associated with an apparatus ID of the second apparatus.SELECTED DRAWING: Figure 5

Description

  The present invention relates to a device management apparatus, a device management system, a device management method, and a program.

  For example, when using a device such as an image forming apparatus installed in an office, it is necessary to take measures according to the state of the device, such as replenishment of consumables, error recovery, and charging according to the usage amount. For this reason, it is necessary to manage the apparatus so that the state of the apparatus can be grasped. However, it is extremely troublesome to manually manage the apparatus individually. In view of this, a device management system that centrally manages each device using a device management device on a network has been proposed.

  For example, in Patent Document 1, a device management apparatus on a network collects device information (number of printed sheets, error information, etc.) indicating the status of each device from a plurality of devices via the network, and associates the device information with device identification information. A device management system to be stored is described. Further, in Patent Document 2, a device management apparatus on a network stores setting information according to a user input in association with device identification information, and transmits setting information to the device in response to a request from the device. The device management system to be reflected is described. Further, in Patent Document 3, a device management apparatus on a network collects a usage amount (counter value) from a plurality of devices via a network, stores it in association with device identification information (device serial number), and collects it. A device management system that calculates a usage fee based on a usage amount and a contract type and presents it to a user is described.

  In the above-described conventional device management system, the device management apparatus manages various information for each individual device. However, some information to be managed is preferably managed for each device that is regarded as the same by the user's cognitive identification rather than managed as device-specific information. That is, the identification of the device by the user is often a cognitive identification based on the installation environment of the device, such as “a printer in a conference room on the third floor”. When a device is replaced with another device due to a failure or the like, the device before replacement and the device after replacement are regarded as the same device by cognitive identification. For this reason, it is often desired to transfer the settings of the device before replacement to the device after replacement, or to collect the usage amount consistently between the device before replacement and the device after replacement.

  However, in the conventional device management system, such cognitive identification is not reflected in management, and even devices that are regarded as the same by cognitive identification are treated as individual devices. For this reason, when the above-mentioned device replacement is performed, in order to transfer the settings of the device before replacement to the device after replacement, an operation for applying the settings of the device before replacement to the device after replacement is performed. It must be done manually. In addition, in order to aggregate the usage amount consistently between the device before replacement and the device after replacement, individually set conditions that add the usage amount of the replaced device to the usage amount of the device before replacement. It is necessary to aggregate usage. As described above, in the conventional device management system, information cannot be managed for each device that is regarded as the same by cognitive identification.

  In order to solve the above-described problem, the present invention issues management identification information for managing a device, and generates mapping information in which device identification information for identifying a device is associated with the management identification information. A mapping management unit; and a device validity management unit that generates validity management information in which validity indicating whether the device is valid or invalid is associated with the device identification information. The device validity management unit includes a first device. Generating the validity management information for which the validity is invalid and generating the validity management information for which the validity is valid for a second device treated as the same device as the first device, A mapping management unit generates the mapping information in which the device identification information of the second device is associated with the management identification information associated with the device identification information of the first device.

  According to the present invention, it is possible to treat devices that are regarded as the same by cognitive identification as the same device, and to reduce the management effort.

FIG. 1 is a system configuration diagram illustrating an overview of a device management system according to an embodiment. FIG. 2 is a block diagram illustrating an example of a hardware configuration of the device management apparatus. FIG. 3 is a block diagram illustrating an example of the hardware configuration of the device. FIG. 4 is a block diagram illustrating an example of a hardware configuration of the management terminal. FIG. 5 is a block diagram illustrating a functional configuration example of the device management apparatus. FIG. 6 is a diagram illustrating an example of a data structure of user information. FIG. 7 is a diagram illustrating an example of a data structure of service management information. FIG. 8 is a diagram illustrating an example of a data structure of validity management information. FIG. 9 is a diagram illustrating an example of a data structure of mapping information. FIG. 10 is a diagram illustrating an example of a data structure of history information. FIG. 11 is a block diagram illustrating a functional configuration example of a device. FIG. 12 is a block diagram illustrating a functional configuration example of the management terminal. FIG. 13 is a diagram illustrating an example of a menu screen. FIG. 14 is a diagram illustrating an example of a user registration screen. FIG. 15 is a diagram illustrating an example of a login screen. FIG. 16 is a diagram illustrating an example of a service purchase screen. FIG. 17 is a diagram illustrating an example of a device registration screen. FIG. 18 is a diagram illustrating an example of an installation registration screen. FIG. 19 is a diagram illustrating an example of a removal registration screen. FIG. 20 is a diagram illustrating an example of a replacement registration screen. FIG. 21 is a diagram illustrating an example of a setting change screen. FIG. 22 is a diagram illustrating an example of a usage amount aggregation screen. FIG. 23 is a diagram illustrating an example of a device status list screen. FIG. 24 is a flowchart illustrating an operation example of user registration processing. FIG. 25 is a flowchart illustrating an operation example of authentication processing. FIG. 26 is a flowchart illustrating an operation example of service purchase processing. FIG. 27 is a sequence diagram illustrating an operation example from a user registration process to a service purchase process. FIG. 28 is a flowchart illustrating an operation example of installation registration processing. FIG. 29 is a flowchart illustrating an operation example of the mapping registration process. FIG. 30 is a flowchart illustrating an operation example of the mapping ID additional registration process. FIG. 31 is a sequence diagram illustrating an operation example of the installation registration process including the mapping registration process and the mapping ID additional registration process. FIG. 32 is a flowchart illustrating an operation example of removal registration processing. FIG. 33 is a flowchart illustrating an operation example of the mapping release processing. FIG. 34 is a sequence diagram illustrating an operation example of the removal registration process including the mapping cancellation process. FIG. 35 is a flowchart illustrating an operation example of replacement registration processing. FIG. 36 is a flowchart illustrating an operation example of the mapping change process. FIG. 37 is a sequence diagram illustrating an operation example of the replacement registration process including the mapping change process. FIG. 38 is a flowchart illustrating an operation example of the setting change process. FIG. 39 is a flowchart illustrating an operation example of setting synchronization processing in the device. FIG. 40 is a flowchart illustrating an operation example of setting synchronization processing in the device management apparatus. FIG. 41 is a flowchart illustrating an operation example of the old device ID search process. FIG. 42 is a sequence diagram illustrating an operation example of the history information accumulation process. FIG. 43 is a flowchart illustrating an operation example of the usage amount totaling process. FIG. 44 is a flowchart illustrating an operation example of device state list generation processing. FIG. 45 is a diagram illustrating a data model assumed in the second embodiment. FIG. 46 is a system configuration diagram showing an overview of the device management system of the second embodiment. FIG. 47 is a block diagram illustrating a functional configuration example of the device management apparatus. FIG. 48 is a diagram for explaining the outline of the request receiving unit. FIG. 49 is a diagram illustrating an example of a data structure of group information. FIG. 50 is a diagram illustrating an example of the data structure of the counter information. FIG. 51 is a diagram illustrating an example of a data structure of usage restriction information. FIG. 52 is a diagram illustrating a screen example of the management tool. FIG. 53 is a diagram showing an example of the setting input screen. FIG. 54 is a diagram illustrating an example of a setting input screen. FIG. 55 is a diagram illustrating an example of a setting input screen. FIG. 56 is a sequence diagram illustrating an operation example in response to a counter information acquisition request. FIG. 57-1 is a diagram illustrating a data example of a counter information acquisition request. FIG. 57-2 is a diagram of a data example of a response to the counter information acquisition request. FIG. 58 is a sequence diagram illustrating an operation example according to the usage restriction information acquisition request. FIG. 59A is a diagram illustrating a data example of the usage restriction information acquisition request. FIG. 59-2 is a diagram illustrating an example of data of a response to the usage restriction information acquisition request. FIG. 60 is a sequence diagram illustrating an operation example in response to a usage restriction setting request. FIG. 61A is a diagram of a data example of a usage restriction setting request. FIG. 61B is a diagram of a data example of a response to the use restriction setting request.

  Hereinafter, specific embodiments of a device management apparatus, a device management system, a device management method, and a program according to the present invention will be described in detail with reference to the accompanying drawings.

[First Embodiment]
<System configuration>
First, the outline | summary of the apparatus management system of this embodiment is demonstrated. FIG. 1 is a system configuration diagram showing an overview of a device management system 1 of the present embodiment. As shown in FIG. 1, the device management system 1 includes a device management apparatus 10, a plurality of devices 20 to be managed, and a management terminal 30 operated by a user for managing the devices 20. The plurality of devices 20 and the management terminal 30 are communicably connected to the device management apparatus 10 via the network 40.

  The device management apparatus 10 is a server device that provides various services related to the management of the device 20. Services provided by the device management apparatus 10 include, for example, management of setting information of the device 20, collection of log information and history information, and collection and management of status information. In the present embodiment, it is assumed that the device management apparatus 10 provides these various services as a cloud service. Therefore, the network 40 is a combination of the Internet, a LAN (Local Area Network), a wireless LAN, and the like. The device management system 1 can be realized in a local area. In this case, a LAN or the like provided in a limited environment is used as the network 40.

  In the present embodiment, an image forming apparatus such as an MFP (Multifunction Peripheral / Printer) is assumed as the device 20 to be managed. However, the type of the device 20 is not particularly limited. The number of devices 20 to be managed is arbitrary, and various devices 20 registered in the device management apparatus 10 and connected to the network 40 can be managed.

  In the present embodiment, the management terminal 30 is assumed to be an information processing apparatus such as a PC (Personal Computer), a tablet terminal, or a smartphone. The management terminal 30 is used for making various requests to the device management apparatus 10 without the user directly operating the device 20, but is not essential. In other words, the device management system 1 according to the present embodiment only needs to include at least the device management apparatus 10 and one or more devices 20 connected to the device management apparatus 10 via the network 40.

<Hardware configuration example of device management device>
Next, a hardware configuration example of the device management apparatus 10 will be described. The device management apparatus 10 can use a general computer as specific hardware. FIG. 2 is a block diagram illustrating an example of a hardware configuration of the device management apparatus 10. For example, as shown in FIG. 2, the device management apparatus 10 includes a CPU (Central Processing Unit) 101, a RAM (Random Access Memory) 102, a ROM (Read Only Memory) 103, and a nonvolatile memory 104 such as a hard disk or a flash memory. And a network I / F 105 which is a communication interface connected to the network 40, and these are connected by a bus 106.

  In the device management apparatus 10 of the present embodiment, the CPU 101 reads out and executes a predetermined program stored in the ROM 103, the nonvolatile memory 104, or the like, using the RAM 102 as a work area, thereby performing various functions described later. Realized. That is, the device management apparatus 10 according to the present embodiment realizes various functions to be described later for providing various services related to the management of the device 20 in cooperation with computer hardware and software (program).

  Although FIG. 2 shows hardware of a single computer, the device management apparatus 10 of this embodiment may be realized by a combination of a plurality of computers. That is, a configuration may be employed in which functional components described later of the device management apparatus 10 are distributed among a plurality of computers. In this case, the plurality of computers constituting the device management apparatus 10 may be communicably connected via the network 40 or may be directly connected by a cable.

<Device hardware configuration example>
Next, a hardware configuration example of the device 20 will be described. FIG. 3 is a block diagram illustrating an example of a hardware configuration of the device 20. For example, as illustrated in FIG. 3, the device 20 includes a CPU 201, a RAM 202, a ROM 203, a nonvolatile memory 204 such as a hard disk or a flash memory, a network I / F 205 that is a communication interface connected to the network 40, and an input / output I / F 206 and a device 207 connected to the input / output I / F 206, and each part except for the device 207 is connected by a bus 208. The device 207 is a module that executes an original function of the device 20. When the device 20 is an MFP, the device 207 includes a printer engine, a scanner engine, an engine controller, a FAX transmission / reception unit, an operation panel, and the like.

  In the device 20 of the present embodiment, the CPU 201 reads out and executes a predetermined program stored in the ROM 203, the nonvolatile memory 204, or the like using the RAM 202 as a work area, thereby realizing various functions described below. The

<Hardware configuration example of management terminal>
Next, a hardware configuration example of the management terminal 30 will be described. FIG. 4 is a block diagram illustrating an example of a hardware configuration of the management terminal 30. For example, as shown in FIG. 4, the management terminal 30 includes a CPU 301, a RAM 302, a ROM 303, a nonvolatile memory 304 such as a hard disk and a flash memory, a network I / F 305 that is a communication interface connected to the network 40, and an input / output An I / F 306, a display panel 307 and an operation input device 308 connected to the input / output I / F 306 are provided, and each unit excluding the display panel 307 and the operation input device 308 is connected by a bus 309. The display panel 307 is a module that displays various types of information so that the user can browse. For example, a liquid crystal display panel is used. The operation input device 308 is a device used by a user to input a request to the device management apparatus 10, and for example, a mouse, a keyboard, a touch panel, or the like is used.

  In the management terminal 30 of the present embodiment, the CPU 301 uses the RAM 302 as a work area and reads and executes a predetermined program stored in the ROM 303, the nonvolatile memory 304, or the like, thereby realizing the functions described below. .

<Functional configuration of device management device>
Next, the functional configuration of the device management apparatus 10 will be described. FIG. 5 is a block diagram illustrating a functional configuration example of the device management apparatus 10. As shown in FIG. 5, for example, as shown in FIG. 5, the device management apparatus 10 includes a request reception unit 11, a user management unit 12, and the like as functional components realized by the cooperation of the hardware and software (program) described above. A service management unit 13, a device validity management unit 14, a mapping management unit 15, a setting management unit 16, a usage history management unit 17, and a state management unit 18.

  The request receiving unit 11 is a functional module that provides a user with an interface for receiving a request to the device management apparatus 10. Specifically, when the user operates the device 20 to input a request to the device management apparatus 10, the request reception unit 11 displays a predetermined interface screen on the operation panel of the device 20, for example. When the user operates the management terminal 30 to input a request for the device management apparatus 10, the request reception unit 11 displays a predetermined interface screen on the display panel 307 of the management terminal 30. Then, the request receiving unit 11 receives a request input by the user performing a predetermined operation on the interface screen, and sends the request to another corresponding functional module.

  In the present embodiment, a user registration request, a service purchase request, a device registration request, a setting change request, a usage amount totaling request, a device status list request, and the like are assumed as requests that the user makes to the device management apparatus 10.

  The user registration request is a request for registration as a user of the device management system 1. When the request reception unit 11 receives a user registration request in response to a user operation on the interface screen, the request reception unit 11 passes the request to the user management unit 12.

  The service purchase request is a request for purchasing a service executed using the device 20, such as a print service or a scan service. When the request reception unit 11 receives a service purchase request in response to a user operation on the interface screen, the request reception unit 11 passes the request to the service management unit 13.

  The device registration request is a request made by the user in accordance with installation, removal, and replacement of the device 20. That is, when the user newly installs the device 20, installation registration is requested. When the user removes the installed device 20, removal registration is requested. In addition, when the device 20 (hereinafter referred to as an old device) that has been installed so far is removed and replaced with a new device 20 (hereinafter referred to as a new device), the user registers for replacement. Request. When the request reception unit 11 receives such a device registration request in response to a user operation on the interface screen, the request reception unit 11 passes the request to the device validity management unit 14.

  The setting change request is a request for changing the setting of the device 20. When the request reception unit 11 receives a setting change request in response to a user operation on the interface screen, the request reception unit 11 passes the request to the setting management unit 16.

  The usage amount totaling request is a request for totaling the usage amount of the service purchased by the user. When the request reception unit 11 receives a usage amount totaling request in response to a user operation on the interface screen, the request reception unit 11 passes this request to the usage history management unit 17.

  The device status list request is a request for displaying a list of the statuses of all devices 20 used by the user. The state of the device 20 here is, for example, the remaining amount of paper or toner, the presence or absence of an error, and the like. Upon receiving a device status list request in response to a user operation on the interface screen, the request receiving unit 11 passes this to the status management unit 18.

  In the device management system 1 according to the present embodiment, the user can make the above-described various requests to the device management apparatus 10 by performing a predetermined operation on the interface screen provided by the request reception unit 11. The details of the operation performed on the interface screen by the user will be described later together with a specific example of the interface screen provided by the request receiving unit 11.

  In the present embodiment, the request receiving unit 11 is described as being included in the device management apparatus 10, but the device 20 and the management terminal 30 may be configured to include the request receiving unit 11. In this case, a user request received by the request receiving unit 11 of the device 20 or the management terminal 30 is transmitted to each corresponding functional module of the device management apparatus 10 via the network 40.

  The user management unit 12 is a functional module that executes generation and retention of user information in response to a user registration request, user authentication processing using the user information, and the like.

  FIG. 6 is a diagram illustrating an example of a data structure of user information generated by the user management unit 12. The user information is information related to the user of the device management system 1, and is registered and held in a user management table T1 constructed in the nonvolatile memory 104, for example, as shown in FIG.

  As shown in FIG. 6, the user management table T1 includes a “user ID” column C11 for storing a user ID, a “detailed information” column C12 for storing detailed information, and a “login ID” for storing a login ID. Column C13, a “password” column C14 for storing a password, and a “mapping ID” column C15 for storing a mapping ID.

  The user ID is user identification information for identifying a user. Upon receiving the user registration request from the request receiving unit 11, the user management unit 12 issues a user ID and registers it in the “user ID” column C11 of the user management table T1.

  Detailed information is information input by the user at the time of user registration. When detailed information is input at the time of user registration, the user management unit 12 receives the detailed information together with the user registration request from the request reception unit 11, and registers it in the “detailed information” column C12 of the user management table T1. .

  The login ID and password are account information used for user authentication, and are input by the user at the time of user registration. As an example of the login ID, an e-mail address used by the user can be used. The user management unit 12 receives the login ID and password together with the user registration request from the request reception unit 11, and registers them in the “login ID” column C13 and the “password” column C14 of the user management table T1. When the user management unit 12 receives the login ID and password together with the login request from the request reception unit 11, the user management unit 12 compares the received login ID and password with the login ID and password registered in the user management table T1, and uses the login ID and password. Authenticate

  In the device management system 1 of the present embodiment, the user can log in to the device management apparatus 10 using an account registered in SNS (Social Networking Service). In this case, user authentication processing (external authentication) is performed by the SNS designated by the user, and the authentication result is notified to the device management apparatus 10.

  The mapping ID is management identification information for managing the device 20, and is issued by the mapping management unit 15 when installation registration of the device 20 is requested. In response to the mapping ID registration request from the mapping management unit 15, the user management unit 12 specifies a user ID to be associated with the mapping ID, and among the entries of the user management table T1, the specified user ID is registered. The mapping ID is additionally registered in the “mapping ID” column C15 of the entry. In this embodiment, in the user information, a user ID and one or more mapping IDs are associated.

  The service management unit 13 is a functional module that executes generation and retention of service management information according to a service purchase request.

  FIG. 7 is a diagram illustrating an example of a data structure of service management information generated by the service management unit 13. The service management information is information related to the service purchased by the user, and is registered and held in a service management table T2 constructed in the nonvolatile memory 104, for example, as shown in FIG. The service purchased by the user is different from the service related to the management of the device 20 described above, and is a print service or a scan service executed using the device 20.

  As shown in FIG. 7, the service management table T2 includes a “service ID” column C21 for storing a service ID, a “service name” column C22 for storing a service name, and a “user ID” for storing a user ID. Column C23.

  The service ID is service identification information for identifying the service purchased by the user, and the service name is a name given to the service. When the service management unit 13 receives a service purchase request designating a service to be purchased from the request reception unit 11, the service management unit 13 issues a service ID and registers it in the “service ID” column C21 of the service management table T2, and the user purchases it. The service name of the service to be registered is registered in the “service name” column C22. Further, the service management unit 13 identifies the user ID of the user who purchased the service and registers it in the “user ID” column C23 of the service management table T2.

  The device validity management unit 14 is a functional module that generates, holds, and rewrites validity management information in response to a device registration request. The device validity management unit 14 requests the mapping management unit 15 to perform mapping registration when the device registration request is an installation registration request.

  FIG. 8 is a diagram illustrating an example of a data structure of validity management information generated by the device validity management unit 14. The validity management information is information related to the registered device 20, and particularly includes information indicating validity indicating whether the device 20 is valid or invalid. Here, that the device 20 is valid means that the device 20 is installed so as to be able to execute services such as printing and scanning. On the other hand, that the device 20 is invalid means that the device 20 is removed and services such as printing and scanning cannot be performed. For example, as shown in FIG. 8, the validity management information is registered and held in a device validity management table T3 constructed in the nonvolatile memory 104 or the like.

  As illustrated in FIG. 8, the device validity management table T3 stores a “device ID” column C31 that stores a device ID, a “device name” column C32 that stores a device name, and a location where the device 20 is installed. "Installation location" column C33, "Effectiveness (state)" column C34 for storing the above-described validity (state), "Start date and time" column C35 for storing the start date and time, and "End date and time" for storing the end date and time Column C36.

  The device ID is identification information for identifying the individual device 20, and for example, a unique machine number (serial number) assigned to the device 20 in advance can be used as the device ID. In the present embodiment, each device 20 to be managed stores its own device ID, and when communicating with the device management apparatus 10, the device management apparatus 10 is notified of its own device ID. The device name is a name given to the device 20 and is input by the user together with the installation location of the device 20 when the device 20 is registered. The device validity management unit 14 receives the device ID, the device name, and the installation location of the device 20 together with the device registration request from the request reception unit 11, and the “device ID” column C31, “device name” in the device validity management table T3. They are registered in the column 32 and the “installation location” column 33, respectively.

  As described above, the validity (state) is information indicating whether the device 20 is valid or invalid. In other words, the device 20 in which the validity (state) is valid (installed) is in a state of being installed so that services such as printing and scanning can be executed, and the validity (status) is invalid (removed). This indicates that the device 20 has been removed and cannot perform services such as printing and scanning. When the device registration request received from the request reception unit 11 is an installation registration request, the device validity management unit 14 registers validity (installation) in the “validity (state)” column C34 of the device validity management table T3. . That is, the device validity management unit 14 generates validity management information with validity (installation) validity (installation) for the device 20 to be installed in response to the installation registration request. On the other hand, when the device registration request received from the request reception unit 11 is a removal registration request, the device validity management unit 14 among the entries of the device validity management table T3, the device ID of the device 20 to be removed. Is rewritten as invalid (removed) from the valid (installed) registered in the “validity (status)” column C34 of the entry registered. That is, the device validity management unit 14 generates validity management information whose validity (state) is invalid (removed) for the device 20 to be removed in response to the removal registration request.

  When the device registration request received from the request receiving unit 11 is a replacement registration request, the device validity management unit 14 includes the device ID of the old device (first device) among the entries of the device validity management table T3. In the “validity (state)” column C34 of the registered entry, the validity (installation) registered in the C34 is rewritten to invalid (removal), and the “validity” of the entry in which the device ID of the new device (second device) is registered. (Status) ”Valid (installation) is registered in the column C34. In other words, in response to the replacement registration request, the device validity management unit 14 generates validity management information whose validity (state) is invalid (removed) for the old device, and the new device 20 that is treated as the same device 20 as the old device. Validity management information with validity (installation) validity (installation) is generated for the device. Since the new device is handled as the same device 20 as the old device, the information on the old device is applied as it is to the device name and installation location of the new device.

  In the present embodiment, either valid (installation) or invalid (removal) is registered in the “validity (status)” column C34 of the device validity management table T3. For example, other information such as invalidity (lock) indicating that the device 20 is installed but the service cannot be executed may be registered. Invalidity (lock) is registered in the “validity (status)” column C34 when, for example, the usage amount of a service such as printing or scanning executed using the device 20 reaches a contract upper limit value. When the usage amount is reset, it is rewritten as valid (installed).

  The start date and time is time information indicating the date and time when validity management information with validity (installation) validity (installation) is generated. The end date and time is time information indicating the date and time when the validity (state) is rewritten to invalid (removed). When the device registration request received from the request reception unit 11 is an installation registration request, the device validity management unit 14 receives, for example, the time (date and time) when the registration request is received in the “start date and time” column C35 of the device validity management table T3. ) As the start date and time. On the other hand, when the device registration request received from the request reception unit 11 is a removal registration request, the device validity management unit 14 receives, for example, a registration request in the “end date and time” column C36 of the device validity management table T3. Register (date and time) as the end date and time.

  When the device registration request received from the request receiving unit 11 is a replacement registration request, the device validity management unit 14 receives, for example, the registration request in the “end date and time” column C36 of the entry corresponding to the old device. (Date and time) is registered as the end date and time, and the time (date and time) when the registration request is received is registered as the start date and time in the “start date and time” column C35 of the entry corresponding to the new device. The device validity management table T3 shown in FIG. 8 shows an example in which the start date / time and end date / time are registered in units of days. However, the start date / time and end date / time are set in units of finer hours, minutes, seconds, and the like. It is good also as a structure to register.

  The mapping management unit 15 is a functional module that generates and holds mapping information in response to a mapping registration request from the device validity management unit 14. Moreover, the mapping management part 15 requests | requires registration of mapping ID with respect to the user management part 12, when valid mapping information is produced | generated.

  FIG. 9 is a diagram illustrating an example of a data structure of mapping information generated by the mapping management unit 15. The mapping information is information in which the mapping ID and the device ID are associated with each other, and is registered and held in a mapping management table T4 constructed in the nonvolatile memory 104, for example, as shown in FIG.

  As shown in FIG. 9, the mapping management table T4 includes a “mapping ID” column C41 that stores a mapping ID, a “device ID” column C42 that stores a device ID, and a “start date and time” column C43 that stores a start date and time. And an “end date and time” column C44 for storing the end date and time.

  As described above, the mapping ID is management identification information for managing the device 20, and is logical identification information for treating the devices 20 that are regarded as the same by the user's cognitive identification as the same. It is. That is, in order to handle the new device replaced from the old device in response to the above replacement registration request as the same device 20 as the old device, a common mapping ID is used between the old device and the new device. Upon receiving the mapping registration request from the device validity management unit 14, the mapping management unit 15 issues a mapping ID and registers it in the “mapping ID” column C41 of the mapping management table T4, and receives the device ID received together with the mapping registration request. Is registered in the “device ID” column C42. Thereby, the device ID designated by the device validity management unit 14 is associated with the newly issued mapping ID.

  In addition, when the mapping management unit 15 receives the device ID of the old device and the device ID of the new device together with the mapping change request from the device validity management unit 14, the mapping management table 15 among the entries of the mapping management table T4 The mapping ID registered in the “mapping ID” column C41 of the entry in which the ID is registered is copied to the “mapping ID” column C41 of the new entry, and the new device has a “device ID” column C42 of the new entry. Register the device ID. As a result, the device ID of the new device is associated with the mapping ID associated with the device ID of the old device.

  The start date and time is time information (first time information) representing the date and time when the device ID is associated with the mapping ID. The end date and time is time information (second time information) indicating the date and time when the association of the device ID with the mapping ID is canceled. In the present embodiment, mapping information in which the start date / time is registered in the “start date / time” column C43 of the mapping management table T4 and the end date / time is not registered in the “end date / time” column C44 is treated as valid mapping information. The mapping information whose end date and time is registered in the column C44 is handled as invalid mapping information. The valid mapping information indicates that the association of the device ID with the mapping ID is valid, and the invalid mapping information indicates that the association of the device ID with the mapping ID is canceled and becomes invalid.

  When the mapping management unit 15 associates the mapping ID with the device ID in response to the mapping registration request or the mapping change request from the device validity management unit 14, the “start date” of the corresponding entry in the mapping management table T4. For example, the time (date and time) at which a mapping registration request or mapping change request is received is registered as a start date and time in the column C43. That is, in this case, the mapping management unit 15 generates valid mapping information.

  On the other hand, when the mapping management unit 15 receives the device ID together with the mapping release request from the device validity management unit 14, the “end date and time” of the entry in which the received device ID is registered among the entries of the mapping management table T4. In column C44, for example, the time (date and time) when the mapping release request is received is registered as the end date and time, and the mapping information is invalidated. In addition, when the mapping management unit 15 receives a mapping change request from the device validity management unit 14, the entry in which the device ID of the old device received with the mapping change request is registered among the entries of the mapping management table T4. In the “end date and time” column C44, for example, the time (date and time) when the mapping change request is received is registered as the end date and time, and the mapping information is invalidated. That is, in these cases, the mapping management unit 15 generates invalid mapping information.

  The mapping management table T4 shown in FIG. 9 shows an example in which the start date / time and end date / time are registered in units of days, but the start date / time and end date / time are registered in units of finer hours, minutes, seconds, and the like. It is good also as a structure.

  The setting management unit 16 is a functional module that holds setting information related to the setting of the device 20 in association with the device ID. The setting of the device 20 is, for example, a printer setting or a scanner setting of the device 20. Examples of setting information related to printer settings include paper feed tray settings, paper type, paper thickness, and paper discharge destination. Examples of the setting information related to the scanner setting include color determination, standby for the next original, automatic density setting, blank page detection, and the like. In addition to the above, the setting information related to the setting of the device 20 may include other setting items such as the setting of the language used.

  Further, when receiving a setting change request from the request receiving unit 11, the setting management unit 16 changes the setting information associated with the device ID received together with the setting change request in response to the request.

  Further, when receiving a setting information request from the device 20, the setting management unit 16 transmits setting information associated with the device ID (first device identification information) received together with this request to the requesting device 20. At this time, when the setting management unit 16 does not hold the setting information associated with the device ID received from the device 20, the setting management unit 16 instructs the mapping management unit 15 to associate the mapping ID with the device ID. Is requested to acquire the device ID (second device identification information) whose association has been released. The mapping management unit 15 can acquire the requested device ID by searching for invalid mapping information including the mapping ID associated with the designated device ID. The setting management unit 16 associates the setting information associated with the device ID acquired by the mapping management unit 15 with the device ID received together with the setting information request, and transmits the setting information to the requesting device 20. . Thereby, when the old device is replaced with the new device by the replacement of the device 20, the setting information of the old device can be taken over as the setting information of the new device.

  The usage history management unit 17 is a functional module that retains log information regarding the usage amount collected from a device 20 as history information in association with a service ID for identifying a service applied to the device 20. Further, when the usage history management unit 17 receives a usage amount totaling request from the request receiving unit 11, the usage history management unit 17 extracts log information associated with the service ID received together with the usage amount totaling request from the log information held as history information. Total usage of services such as print service and scan service. Then, the usage history management unit 17 responds to the request receiving unit 11 with the usage amount totaling result. In this case, the request reception unit 11 displays the usage amount total result received from the usage history management unit 17 so that the user can view it.

  FIG. 10 is a diagram illustrating an example of a data structure of history information held by the usage history management unit 17. The history information is registered and held in a history management table T5 constructed in the nonvolatile memory 104 or the like, for example, as shown in FIG.

  As shown in FIG. 10, the history management table T5 includes a “service ID” column C51 for storing a service ID, a “log type” column C52 for storing a log type, and a “usage amount” column C53 for storing a usage amount. Including.

  In this embodiment, each time a job such as printing or scanning is executed in the device 20, log information regarding the executed job is sent from the device 20 to the usage history management unit 17 of the device management apparatus 10. Shall be sent with. This log information includes a log type indicating what kind of job the log information is, and a usage amount indicating the number of printed sheets, the number of scanned pages, the data size of the printed or scanned data, and the like.

  When the log information from the device 20 is received together with the device ID, the usage history management unit 17 acquires a service ID corresponding to the received device ID. Then, the acquired service ID is registered in the “service ID” column C51 of the history management table T5, the log type included in the log information is set as the “log type” column C52, and the usage amount included in the log information is set as “usage amount”. Register each in column C53.

  Here, a procedure for acquiring the service ID based on the device ID will be described. Since the service management unit 13 holds the service ID as service management information, the usage history management unit 17 requests the service management unit 13 to acquire a service ID associated with the device ID. Since the service management unit 13 holds service management information in which a service ID and a user ID are associated with each other, the service management unit 13 requests the user management unit 12 to acquire a user ID associated with the device ID. Since the user management unit 12 holds user information in which the user ID and the mapping ID are associated with each other, the user management unit 12 requests the mapping management unit 15 to acquire a mapping ID associated with the device ID.

  In response to a request from the user management unit 12, the mapping management unit 15 acquires a mapping ID associated with the device ID based on the mapping information held and responds to the user management unit 12. The user management unit 12 acquires a user ID associated with the mapping ID acquired by the mapping management unit 15 based on the held user information and responds to the service management unit 13. The service management unit 13 acquires a service ID associated with the user ID acquired by the user management unit 12 based on the held service management information and responds to the usage history management unit 17. Through the above procedure, the service ID associated with the device ID received from the device 20 along with the log information by the usage history management unit 17 is acquired. The usage history management unit 17 can store the log information received from the device 20 as a usage history in association with the service ID acquired as described above.

  The state management unit 18 is a functional module that collects state information representing the state of the device 20 from the device 20 and retains it in association with the device ID. The device state here is, for example, the remaining amount of paper or toner, the presence or absence of an error, as described above. Further, when the state management unit 18 receives a device state list request from the request reception unit 11, the state management unit 18 acquires the device IDs of all the devices 20 used by the user who has input the request, and the state associated with the acquired device ID. Information is extracted and the request reception unit 11 is responded. In this case, the request reception unit 11 aggregates the state information received from the state management unit 18 to generate a device state list screen and displays the device state list screen so that the user can view it.

  In the present embodiment, the configuration in which the state management unit 18 holds the state information representing the state of the device 20 as information different from the history information held in the usage history management unit 17 is exemplified. The configuration may be such that state information collected from the device 20 is held as part of the history information held by the device 17.

<Functional configuration of device>
Next, the functional configuration of the device 20 will be described. FIG. 11 is a block diagram illustrating a functional configuration example of the device 20. For example, as illustrated in FIG. 11, the device 20 includes a status transmission unit 21, a log transmission unit 22, and setting synchronization as functional components realized by the cooperation of the hardware and software (program) described above. Unit 23, display unit 24, and request transmission unit 25.

  The status transmission unit 21 is a functional module that transmits the status of the device 20 such as the remaining amount of paper and toner and the presence or absence of an error to the device management apparatus 10. For example, the status transmission unit 21 checks the remaining amount of paper and toner regularly or at a predetermined timing, and detects that the remaining amount of paper or toner is equal to or less than a threshold value. The device 10 is notified. At this time, if a plurality of threshold values are set, the remaining amount of paper and toner can be notified at a plurality of levels. In addition, when an error occurs in the device 20, the status transmission unit 21 notifies the device management apparatus 10 that the error has occurred, together with the content of the error, and when the error is cleared, the device indicates that the error has been cleared. Notify the management device 10.

  The log transmission unit 22 is a functional module that transmits log information regarding jobs such as printing and scanning executed in the device 20 to the device management apparatus 10. Each time a job such as printing or scanning is executed in the device 20, the log transmission unit 22 generates log information including the log type and the usage amount described above, and transmits the generated log information to the device management apparatus 10. .

  The setting synchronization unit 23 requests setting information from the device management apparatus 10 periodically or at a predetermined timing, and acquires setting information held by the setting management unit 16 of the device management apparatus 10. The setting synchronization unit 23 compares the setting information acquired from the device management apparatus 10 with the setting information held by the device 20, and if there is a difference between the two, reflects the difference in the setting of the device 20. The setting information held by the device 20 is updated.

  The display unit 24 is a functional module that displays an interface screen provided by the request reception unit 11 of the device management apparatus 10. The request transmission unit 25 is a functional module that transmits a request input by a user performing a predetermined operation on the interface screen displayed by the display unit 24 to the device management apparatus 10.

<Functional configuration of management terminal>
Next, the functional configuration of the management terminal 30 will be described. FIG. 12 is a block diagram illustrating a functional configuration example of the management terminal 30. As shown in FIG. 12, for example, the management terminal 30 includes a display unit 31 and a request transmission unit 32 as functional components realized by the cooperation of the hardware and software (program) described above.

  The display unit 31 is a functional module that displays an interface screen provided by the request reception unit 11 of the device management apparatus 10. The request transmission unit 32 is a functional module that transmits a request input by a user performing a predetermined operation on the interface screen displayed on the display unit 31 to the device management apparatus 10.

<Specific example of interface screen>
Next, a specific example of the interface screen provided by the request reception unit 11 of the device management apparatus 10 will be described.

  FIG. 13 is a diagram showing an example of a menu screen SC100 that is initially displayed as an interface screen. The menu screen SC100 includes a “user registration” button 1001, a “service purchase” button 1002, a “device registration” button 1003, a “setting change” button 1004, a “usage usage totaling” button 1005, and “ A “device status list” button 1006 is provided. The user can make various requests to the device management apparatus 10 by selectively operating these buttons.

  FIG. 14 is a diagram showing an example of a user registration screen SC200 displayed when the user operates the “user registration” button 1001 on the menu screen SC100 of FIG. First, the user registration screen SC200 is displayed as shown in FIG. When the user inputs a login ID in the text box 2001 and inputs a password in the text box 2002 and operates the “OK” button 2003 on the screen of FIG. 14A, the user registration screen SC200 is displayed. Transition from the screen of FIG. 14A to the screen shown in FIG. Note that even when the user operates any of the external authentication designation buttons 2004 on the screen of FIG. 14A, the user registration screen SC200 is changed from the screen of FIG. 14A to FIG. 14B. Transition to the screen shown.

  Next, when the user inputs detailed information in the text box 2011 on the screen of FIG. 14B and operates the “Register” button 2012, the request reception unit 11 of the device management apparatus 10 receives the user registration request. It is done. The user registration request is sent to the user management unit 12 together with the login ID, password, and detailed information. It is not essential to enter detailed information. That is, even when the user operates the “Register” button 2012 without inputting detailed information in the text box 2011, the user registration request is accepted by the request accepting unit 11, and the user registration request is It is sent to the user management unit 12 together with the login ID and password.

  Thereafter, user information is generated by the user management unit 12 in response to the user registration request, and when the user registration is completed, the user registration screen SC200 is changed from the screen of FIG. 14B to FIG. 14C. The user is notified that the user registration has been completed. Then, when the user operates the “Purchase Service” button 2021 on the screen of FIG. 14C, the interface screen transitions to the service purchase screen. When the user operates the “end” button 2022 on the screen of FIG. 14C, the display of the interface screen is ended.

  FIG. 15 is a diagram illustrating an example of the login screen SC300. When user registration and service purchase are continuously performed, that is, when the user operates the “service purchase” button 2021 on the screen of FIG. 14C, it is not necessary to perform user authentication again. On the other hand, on the menu screen SC100 of FIG. 13, the user selects a “service purchase” button 1002, a “device registration” button 1003, a “setting change” button 1004, a “usage usage totaling” button 1005, and a “device status list” button 1006. When any of the above is operated, user authentication is required, and therefore a login screen SC300 shown in FIG. 15 is displayed first.

  When the user inputs the login ID in the text box 3001 and inputs the password in the text box 3002 and operates the “login” button 3003 on the login screen SC300 in FIG. 15, the request reception unit of the device management apparatus 10 11 accepts a login request. This login request is sent to the user management unit 12 together with the login ID and password, and the user management unit 12 performs an authentication process. When the user operates any of the external authentication designation buttons 3004 on the login screen SC300 in FIG. 15, external authentication is performed with an account registered in the designated SNS. If the result of the authentication process for the user is authentication OK, the user is permitted to log in.

  FIG. 16 shows that when the user operates the “Purchase Service” button 2021 on the screen of FIG. 14C, or the “Purchase Service” button 1002 on the menu screen SC100 of FIG. It is a figure which shows an example of the service purchase screen SC400 displayed when it is performed. First, a screen shown in FIG. 16A is displayed as the service purchase screen SC400. In the screen of FIG. 16A, a list of services using the device 20 managed by the device management apparatus 10 is displayed together with a “purchase” button 4001. This list of services is updated according to the operation of the “next” button 4002. Then, when the user operates the “Purchase” button 4001 corresponding to any service on the screen of FIG. 16A, the service purchase request is received by the request receiving unit 11 of the device management apparatus 10. Then, this service purchase request is sent to the service management unit 13 together with the service name and the user ID.

  Thereafter, when service management information is generated by the service management unit 13 in response to the service purchase request, the service purchase screen SC400 changes from the screen of FIG. 16A to the screen shown in FIG. Is notified to the user, and the service ID issued by the service management unit 13 and the contents of the purchased service are notified to the user. In the case where an e-mail address is registered as the detailed information of the user, the same notification is made with this e-mail address as the destination. When the user operates the “continue purchase” button 4011 on the screen of FIG. 16B, the service purchase screen SC400 returns from the screen of FIG. 16B to FIG. 16A. When the user operates the “return” button 4012 on the screen of FIG. 16B, the screen returns to the menu screen SC100 of FIG. When the user operates the “end” button 4013 on the screen of FIG. 16B, the display of the interface screen is ended.

  FIG. 17 is a diagram showing an example of a device registration screen SC500 displayed when the user operates the “device registration” button 1003 on the menu screen SC100 of FIG. 13 and login is permitted. As described above, the device registration request includes an installation registration request for installing the device 20, a removal registration request for removing the device 20, and a replacement registration request for replacing the old device with a new device. . The device registration screen SC500 is provided with an “install” button 5001, a “remove” button 5002, and a “replace” button 5003 so that the user can select one of these requests.

  FIG. 18 is a diagram showing an example of an installation registration screen SC510 displayed when the user operates the “installation” button 5001 on the device registration screen SC500 of FIG. As the installation registration screen SC510, a screen shown in FIG. 18A is first displayed. Then, the user inputs the device name of the device 20 to be installed in the text box 5101, the installation location in the text box 5102, and the service ID in the text box 5103 on the screen of FIG. Is operated, the request registration unit 11 of the device management apparatus 10 receives the installation registration request.

  In the present embodiment, it is assumed that the device registration request is made from the device 20. That is, it is assumed that a device registration request by the user is input by an operation on the interface screen displayed by the display unit 24 of the device 20. In this case, since the device ID of the device 20 is sent to the device management apparatus 10 together with the request, the user does not need to input the device ID. However, when making a device registration request from the management terminal 30, the user needs to input the device ID of the device 20. Therefore, when accepting a registration request for the device 20 from the management terminal 30, the user is prompted to input a device ID on this interface screen. For example, when the installation registration screen SC510 is displayed on the management terminal 30, a text box for inputting the device ID is added to the screen of FIG. 18A so that the user can input the device ID.

  The installation registration request received by the request receiving unit 11 of the device management apparatus 10 according to the operation on the screen of FIG. 18A is sent to the device validity management unit 14 together with the device ID, device name, and service ID. When the validity management information corresponding to the installation registration request is generated in the device validity management unit 14 and the valid mapping information is generated in the mapping management unit 15, the installation registration screen SC510 is displayed as shown in FIG. A transition is made from the screen a) to the screen shown in FIG. 18B, and a message to the effect that the installation registration of the device 20 has been completed is notified to the user. When the user operates the “return” button 5111 on the screen of FIG. 18B, the screen returns to the menu screen SC100 of FIG. When the user operates the “end” button 5112 on the screen of FIG. 18B, the display of the interface screen ends.

  FIG. 19 is a diagram illustrating an example of a removal registration screen SC520 displayed when removal registration is completed. When the user operates the “removal” button 5002 on the device registration screen SC500 of FIG. 17, the request registration unit 11 of the device management apparatus 10 receives the removal registration request, and the device validity management unit 14 together with the device ID. Sent to. When the validity management information corresponding to the device 20 to be removed is invalidated in the device validity management unit 14 in response to the removal registration request, the mapping information is invalidated in the mapping management unit 15. A removal registration screen SC520 shown in FIG. 19 is displayed, and a message is notified to the user that the removal registration of the device 20 has been completed. When the user operates the “return” button 5201 on the removal registration screen SC520 in FIG. 19, the screen returns to the menu screen SC100 in FIG. Further, when the user operates the “end” button 5202 on the removal registration screen SC520 of FIG. 19, the display of the interface screen is ended.

  FIG. 20 is a diagram showing an example of a replacement registration screen SC530 displayed when the user operates the “replace” button 5003 on the device registration screen SC500 of FIG. First, the screen shown in FIG. 20A is displayed as the replacement registration screen SC530. On the screen of FIG. 20A, a list of devices 20 that are installed by the user, that is, devices 20 that are candidates for old devices, is displayed together with a “select” button 5301. Then, when the user operates the “select” button 5301 corresponding to one of the devices 20 on the screen of FIG. 20A, the replacement registration request is received by the request receiving unit 11 of the device management apparatus 10. That is, a replacement registration request for replacing the device 20 (old device) selected by the user on the replacement registration screen SC530 with the device 20 (new device) displaying the replacement registration screen SC530 is received by the device management apparatus 10 as a request. Accepted by the unit 11. Then, this replacement registration request is sent to the device validity management unit 14 together with the device ID of the old device and the device ID of the new device.

  Thereafter, the validity management information corresponding to the old device is invalidated and the validity management information corresponding to the new device is generated in response to the replacement registration request in the device validity management unit 14. When the mapping information corresponding to the old device is invalidated and the valid mapping information corresponding to the new device is generated, the replacement registration screen SC530 is changed from the screen shown in FIG. 20A to the screen shown in FIG. 20B. The user is notified of a message indicating that the replacement registration of the device 20 has been completed. When the user operates the “return” button 5311 on the screen of FIG. 20B, the screen returns to the menu screen SC100 of FIG. When the user operates the “end” button 5312 on the screen of FIG. 20B, the display of the interface screen is ended.

  FIG. 21 is a diagram showing an example of a setting change screen SC600 displayed when the user operates the “change setting” button 1004 on the menu screen SC100 of FIG. 13 and login is permitted. As the setting change screen SC600, a screen shown in FIG. 21A is first displayed. In the screen of FIG. 21A, a list of devices 20 in the installed state used by the user is displayed together with a “select” button 6001. When the user operates the “select” button 6001 corresponding to one of the devices 20 on the screen of FIG. 21A, the setting change screen SC600 is changed from the screen of FIG. 21A to FIG. ). In the screen of FIG. 21B, current setting information regarding the device 20 selected on the screen of FIG. 21A is displayed together with a check box 6011 and a text box 6012. Then, the user inputs the change contents of the setting information by checking the check box 6011 or inputting a desired value in the text box 6012 on the screen of FIG. When 6013 is operated, a setting change request is received by the request receiving unit 11 of the device management apparatus 10. Then, this setting change request is sent to the setting management unit 16 together with the device ID of the device 20 to be changed, that is, the device ID selected on the screen of FIG.

  Thereafter, when the setting management unit 16 changes the setting information in response to the setting change request, the setting change screen SC600 transitions from the screen of FIG. 21 (b) to the screen shown in FIG. 21 (c). A message is sent to the user that the change is complete. When the user operates the “return” button 6021 on the screen of FIG. 21C, the screen returns to the menu screen SC100 of FIG. When the user operates the “end” button 6022 on the screen of FIG. 21C, the display of the interface screen is ended.

  FIG. 22 is a diagram showing an example of a usage amount totaling screen SC700 displayed when the user operates the “Usage amount totaling” button 1005 on the menu screen SC100 of FIG. 13 and login is permitted. First, a screen shown in FIG. 22A is displayed as the usage amount aggregation screen SC700. Then, when the user inputs a service ID in the text box 7001 and operates the “total” button 7002 on the screen of FIG. 22A, the request reception unit 11 of the device management apparatus 10 receives a usage amount totaling request. It is done. Then, this usage amount totaling request is sent to the usage history management unit 17 together with the designated service ID.

  After that, when the usage history is summed up from all the history information associated with the service ID specified in response to the usage amount totaling request in the usage history management unit 17, the usage amount totaling screen SC700 is displayed as shown in FIG. The screen transitions from the screen to the screen shown in FIG. 22B, and the usage amount totaling result by the usage history management unit 17 is notified to the user. When the user operates the “return” button 7011 on the screen of FIG. 22B, the screen returns to the menu screen SC100 of FIG. When the user operates the “end” button 7012 on the screen of FIG. 22B, the display of the interface screen is ended.

  FIG. 23 is a diagram showing an example of a device state list screen SC800 displayed when the user operates the “device state list” button 1006 on the menu screen SC100 of FIG. 13 and login is permitted. When the user operates the “device status list” button 1006 on the menu screen SC100 of FIG. 13 and login is permitted, the request receiving unit 11 of the device management apparatus 10 receives the device status list request, and the user The ID is sent to the state management unit 18 together with the ID. When the status information of all the devices 20 used by the user is collected in response to the device status list request in the status management unit 18, the device status list screen SC800 shown in FIG. Will be listed. When the user operates the “return” button 8001 on the device status list screen SC800 of FIG. 23, the screen returns to the menu screen SC100 of FIG. Further, when the user operates the “end” button 8002 on the device status list screen SC800 of FIG. 23, the display of the interface screen is ended.

  Note that the configuration of the interface screen described above is merely an example, and the present invention is not limited to this. The interface screen provided by the request accepting unit 11 of the device management apparatus 10 may be configured so that the user can input various requests to the device management apparatus 10, and various modifications and changes to the above-described configuration example are possible. You can make changes.

<Description of operation>
Next, specific examples of main operations in the device management system 1 according to the present embodiment will be described with reference to a flowchart and a sequence diagram.

  FIG. 24 is a flowchart illustrating an operation example of user registration processing. The series of processing shown in the flowchart of FIG. 24 is processing executed when the user management unit 12 receives a user registration request from the request reception unit 11.

  When receiving the user registration request from the request receiving unit 11, the user management unit 12 first issues a user ID (step S101). Then, the user management unit 12 registers the login ID and password received together with the user registration request in association with the user ID issued in step S101 (step S102).

  Next, the user management unit 12 determines whether or not the detailed information is received together with the user registration request, that is, whether or not the detailed information is input by the user (step S103). If the detailed information is input (step S103: Yes), the detailed information received together with the user registration request is registered in association with the user ID issued in step S101 (step S104), and the user registration is performed. The process ends. On the other hand, if the detailed information has not been input (step S103: No), the user registration process is terminated as it is.

  FIG. 25 is a flowchart illustrating an operation example of authentication processing. A series of processes shown in the flowchart of FIG. 25 is a process executed when the user management unit 12 receives a login request from the request reception unit 11.

  When receiving the login request from the request receiving unit 11, the user management unit 12 collates the login ID and password received together with the login request with the user information (step S201), and matches the login ID and the password that are included in the user information. It is determined whether there is a password (step S202). If there is a matching login ID and password (step S202: Yes), an authentication OK response is sent to the request receiving unit 11 (step S203), and the authentication process is terminated. On the other hand, if there is no matching login ID and password (step S202: No), an authentication NG is returned to the request receiving unit 11 (step S204), and the authentication process is terminated.

  FIG. 26 is a flowchart illustrating an operation example of service purchase processing. The series of processes shown in the flowchart of FIG. 26 is a process executed when the service management unit 13 receives a service purchase request from the request reception unit 11.

  When receiving a service purchase request from the request reception unit 11, the service management unit 13 first issues a service ID (step S301). Then, the service management unit 13 registers the service name and user ID received together with the service purchase request in association with the service ID issued in step S301 (step S302), and ends the service purchase process.

  FIG. 27 is a sequence diagram illustrating an operation example from a user registration process to a service purchase process. The sequence diagram of FIG. 27 shows an operation example of the request reception unit 11, the user management unit 12, and the service management unit 13 in response to a user registration request, a login request, and a service purchase request by a user.

  The user registration request by the user is received by the request receiving unit 11 (step S401). Then, the user registration request received by the request receiving unit 11 is sent from the request receiving unit 11 to the user management unit 12 (step S402). The login ID, password, and detailed information input by the user are added to this user registration request.

  Upon receiving the user registration request from the request receiving unit 11, the user management unit 12 issues a user ID and registers user information (step S403). And the user management part 12 responds completion of user registration with respect to the request | requirement reception part 11 (step S404). Upon receiving a user registration completion response from the user management unit 12, the request receiving unit 11 notifies the user of the completion of user registration (step S405).

  Thereafter, when there is a login request by the user, this login request is received by the request receiving unit 11 (step S406). The login request received by the request reception unit 11 is sent from the request reception unit 11 to the user management unit 12 (step S407). A login ID and a password input by the user are added to this login request.

  When receiving the login request from the request reception unit 11, the user management unit 12 performs an authentication process (step S408). Then, the user management unit 12 returns an authentication result to the request reception unit 11 (step S409). Here, it is assumed that the authentication result is authentication OK. The user ID of the user who is authenticated is added to the authentication result of the authentication OK. Upon receiving the authentication OK authentication result from the user management unit 12, the request reception unit 11 permits the user to log in (step S410).

  Thereafter, when there is a service purchase request from the user, this service purchase request is received by the request receiving unit 11 (step S411). Then, the service purchase request received by the request reception unit 11 is sent from the request reception unit 11 to the service management unit 13 (step S412). A user ID and a service name are added to this service purchase request.

  Upon receiving the service purchase request from the request receiving unit 11, the service management unit 13 issues a service ID and registers service management information (step S413). Then, the service management unit 13 sends a service purchase completion response to the request reception unit 11 (step S414). A service ID and a user ID issued by the service management unit 13 are added to this response. Upon receiving a service purchase completion response from the service management unit 13, the request reception unit 11 notifies the user of service purchase completion (step S415). The service ID issued by the service management unit 13 is added to this notification.

  FIG. 28 is a flowchart illustrating an operation example of installation registration processing. A series of processes shown in the flowchart of FIG. 28 is a process executed when the device validity management unit 14 receives an installation registration request from the request reception unit 11.

  Upon receiving the installation registration request from the request reception unit 11, the device validity management unit 14 first checks whether there is valid validity management information corresponding to the device ID received together with the installation registration request (step S501). ). If there is no valid validity management information corresponding to the received device ID (step S501: No), the mapping management unit 15 is requested to perform mapping registration (step S502).

  Thereafter, when a mapping registration OK response is received from the mapping management unit 15 (step S503: Yes), the device validity management unit 14 receives the device ID, the device name, the installation location, and the valid (installation) received together with the installation registration request. The validity management information including the validity indicating () and the start date and time is generated and registered (step S504). Then, the device validity management unit 14 responds with installation OK to the request reception unit 11 (step S505), and ends the installation registration process.

  On the other hand, when there is valid validity management information corresponding to the device ID received together with the installation registration request (step S501: Yes), or when a mapping registration NG response is received from the mapping management unit 15 (step S503: No), the device validity management unit 14 returns an installation NG response to the request reception unit 11 (step S506), and ends the installation registration process.

  FIG. 29 is a flowchart illustrating an operation example of the mapping registration process. The series of processing shown in the flowchart of FIG. 29 is processing executed when the mapping management unit 15 receives a mapping registration request from the device validity management unit 14.

  When receiving the mapping registration request from the device validity management unit 14, the mapping management unit 15 first checks whether there is valid mapping information corresponding to the device ID received together with the mapping registration request (step S601). If there is no valid mapping information corresponding to the received device ID (step S601: No), a mapping ID is issued (step S602), and the device ID received together with the mapping registration request, the start date and time, and the mapping ID are issued. Is generated and registered (step S603).

  Thereafter, the mapping management unit 15 requests the user management unit 12 to additionally register a mapping ID for the user information (step S604), and returns a mapping registration OK to the device validity management unit 14 ( In step S605), the mapping registration process is terminated.

  On the other hand, if there is valid mapping information corresponding to the device ID received together with the mapping registration request (step S601: Yes), the mapping management unit 15 returns a mapping registration NG to the device validity management unit 14 ( Step S606), the mapping registration process is terminated.

  FIG. 30 is a flowchart illustrating an operation example of the mapping ID additional registration process. The series of processing shown in the flowchart of FIG. 30 is processing executed when the user management unit 12 receives a mapping ID additional registration request (mapping ID registration request) from the mapping management unit 15.

  When receiving the mapping ID registration request from the mapping management unit 15, the user management unit 12 first requests the service management unit 13 for a user ID associated with the service ID received together with the mapping ID registration request (step S701). The user ID is acquired from the service management unit 13 (step S702). Then, the user management unit 12 additionally registers the mapping ID received together with the mapping ID registration request for the user information corresponding to the user ID acquired from the service management unit 13 (step S703), and adds the mapping ID. The registration process ends.

  FIG. 31 is a sequence diagram illustrating an operation example of the installation registration process including the mapping registration process and the mapping ID additional registration process. The sequence diagram of FIG. 31 shows an operation example (installation registration) of the request receiving unit 11, the device validity management unit 14, the mapping management unit 15, the user management unit 12 and the service management unit 13 in response to a user's installation registration request. Shows an example of operation when is successful.

  The installation registration request by the user is received by the request receiving unit 11 (step S801). Then, the installation registration request received by the request receiving unit 11 is sent from the request receiving unit 11 to the device validity management unit 14 (step S802). In this installation registration request, the device ID, device name, installation location, and service ID of the device 20 to be installed are added.

  When receiving the installation registration request from the request reception unit 11, the device validity management unit 14 requests the mapping management unit 15 for mapping registration (step S803). In this mapping registration request, a device ID and a service ID received together with the installation registration request from the request reception unit 11 by the device validity management unit 14 are added. When receiving the mapping registration request from the device validity management unit 14, the mapping management unit 15 issues a mapping ID to generate and register mapping information (step S804). The mapping management unit 15 then responds to the device validity management unit 14 with a registration OK mapping registration result (step S805).

  Upon receiving the registration OK mapping registration result from the mapping management unit 15, the device validity management unit 14 generates and registers validity management information corresponding to the installation registration request (step S806). Then, the device validity management unit 14 notifies the request reception unit 11 of the installation registration result of installation OK (step S807). Upon receiving the installation OK installation registration result from the device validity management unit 14, the request reception unit 11 notifies the user of the completion of installation registration (step S808).

  In step S805, the mapping management unit 15 responds to the device validity management unit 14 with a registration OK mapping registration result, and then requests the user management unit 12 to additionally register a mapping ID (step S809). ). The mapping ID registration request includes a mapping ID issued by the mapping management unit 15 and a service ID received by the mapping management unit 15 from the device validity management unit 14 together with the mapping registration request.

  When receiving the mapping ID registration request from the mapping management unit 15, the user management unit 12 requests the service management unit 13 to acquire a user ID (step S810). The service ID received by the user management unit 12 from the mapping management unit 15 together with the mapping ID registration request is added to the user ID acquisition request. Upon receiving the user ID acquisition request from the user management unit 12, the service management unit 13 searches the service management information for a user ID associated with the service ID added to the user ID acquisition request ( In step S811, the user ID is returned to the user management unit 12 (step S812). Then, the user management unit 12 additionally registers a mapping ID for the user information corresponding to the user ID received from the service management unit 13 (step S813).

  FIG. 32 is a flowchart illustrating an operation example of removal registration processing. The series of processing shown in the flowchart of FIG. 32 is processing executed when the device validity management unit 14 receives a removal registration request from the request receiving unit 11.

  Upon receiving the removal registration request from the request receiving unit 11, the device validity management unit 14 first checks whether there is valid validity management information corresponding to the device ID received together with the removal registration request (step S901). ). If there is valid validity management information corresponding to the received device ID (step S901: Yes), the mapping management unit 15 is requested to cancel the mapping (step S902).

  Thereafter, when a response to cancel mapping is received from the mapping management unit 15 (step S903: Yes), the device validity management unit 14 validates the validity management information corresponding to the device ID received together with the replacement registration request. The validity is rewritten from valid (installation) to invalid (removal) and the end date and time are written to invalidate the validity management information (step S904). Then, the device validity management unit 14 sends a removal OK response to the request reception unit 11 (step S905), and ends the removal registration process.

  On the other hand, when there is no effective validity management information corresponding to the device ID received together with the removal registration request (step S901: No), or when a response of mapping removal NG is received from the mapping management unit 15 (step S903: No), the device validity management unit 14 returns removal NG to the request receiving unit 11 (step S906), and ends the removal registration process.

  FIG. 33 is a flowchart illustrating an operation example of the mapping release processing. The series of processes shown in the flowchart of FIG. 33 is a process executed when the mapping management unit 15 receives a mapping release request from the device validity management unit 14.

  When receiving the mapping cancellation request from the device validity management unit 14, the mapping management unit 15 first checks whether there is valid mapping information corresponding to the device ID received together with the mapping cancellation request (step S1001). If there is valid mapping information corresponding to the received device ID (step S1001: Yes), the end date is written in this mapping information, and the mapping information is invalidated (step S1002). Then, a mapping cancellation OK response is sent to the device validity management unit 14 (step S1003), and the mapping cancellation process is terminated.

  On the other hand, when there is no valid mapping information corresponding to the device ID received together with the mapping cancellation request (step S1001: No), the mapping management unit 15 responds to the device validity management unit 14 with a mapping cancellation NG ( In step S1004), the mapping release process is terminated.

  FIG. 34 is a sequence diagram illustrating an operation example of the removal registration process including the mapping cancellation process. The sequence diagram of FIG. 34 shows an operation example of the request accepting unit 11, the device validity management unit 14, and the mapping management unit 15 in response to a removal registration request by a user (an operation example when removal registration is successful). Yes.

  The removal registration request by the user is received by the request receiving unit 11 (step S1101). Then, the removal registration request received by the request reception unit 11 is sent from the request reception unit 11 to the device validity management unit 14 (step S1102). In this removal registration request, the device ID of the device 20 to be removed is added.

  Upon receiving the removal registration request from the request reception unit 11, the device validity management unit 14 requests the mapping management unit 15 to cancel the mapping (step S1103). The device ID received by the device validity management unit 14 from the request receiving unit 11 together with the removal registration request is added to the mapping release request. Upon receiving the mapping release request from the device validity management unit 14, the mapping management unit 15 invalidates the mapping information corresponding to the device ID received together with the mapping release request (step S1104). Then, the mapping management unit 15 responds to the device validity management unit 14 with a release OK mapping release result (step S1105).

  Upon receiving the cancellation OK mapping release result from the mapping management unit 15, the device effectiveness management unit 14 invalidates the validity management information corresponding to the device ID received together with the removal registration request (step S1106). Then, the device validity management unit 14 notifies the request reception unit 11 of the removal registration result of removal OK (step S1107). Upon receiving the removal registration result of removal OK from the device validity management unit 14, the request reception unit 11 notifies the user of completion of removal registration (step S1108).

  FIG. 35 is a flowchart illustrating an operation example of replacement registration processing. The series of processes shown in the flowchart of FIG. 35 is a process executed when the device validity management unit 14 receives a replacement registration request from the request receiving unit 11.

  When the device validity management unit 14 receives the replacement registration request from the request receiving unit 11, first, based on the device name and installation location of the old device received together with the replacement registration request, the device validity management unit 14 determines the effective validity corresponding to the old device. It is confirmed whether there is management information (step S1201). If there is valid validity management information corresponding to the old device (step S1201: Yes), a mapping change is requested to the mapping management unit 15 (step S1202).

  Thereafter, when a response of mapping change OK is received from the mapping management unit 15 (step S1203: Yes), the device validity management unit 14 validates the validity with respect to the validity management information corresponding to the old device (installation). The validity management information is invalidated (step S1204). Further, the device validity management unit 14 receives the device ID of the new device received together with the replacement registration request, the device name and installation location of the old device received together with the replacement registration request, validity indicating the validity (installation), and start. The validity management information corresponding to the new device including the date and time is generated and registered (step S1205). Then, the device validity management unit 14 sends a replacement OK response to the request receiving unit 11 (step S1206), and ends the replacement registration process.

  On the other hand, if there is no valid validity management information corresponding to the old device (step S1201: No), or if a mapping change NG response is received from the mapping management unit 15 (step S1203: No), the device validity The management unit 14 sends a replacement NG response to the request reception unit 11 (step S1207), and ends the replacement registration process.

  FIG. 36 is a flowchart illustrating an operation example of the mapping change process. The series of processing shown in the flowchart of FIG. 36 is processing executed when the mapping management unit 15 receives a mapping change request from the device validity management unit 14.

  Upon receiving the mapping change request from the device validity management unit 14, the mapping management unit 15 first checks whether there is valid mapping information corresponding to the device ID of the old device received together with the mapping change request (step) S1301). If there is valid mapping information corresponding to the device ID of the old device (step S1301: Yes), then whether there is valid mapping information corresponding to the device ID of the new device received together with the mapping change request. Is confirmed (step S1302).

  If there is no valid mapping information corresponding to the device ID of the new device (step S1302: No), the mapping management unit 15 first writes the end date and time in the mapping information corresponding to the device ID of the old device. The mapping information is invalidated (step S1303). Next, the mapping management unit 15 maps the mapping information corresponding to the device ID of the old device, that is, mapping information in which the device ID of the new device and the start date / time are associated with the mapping ID included in the mapping information invalidated in step S1303. Is generated and registered (step S1304). Then, the mapping management unit 15 sends a mapping change OK response to the device validity management unit 14 (step S1305), and ends the mapping change process.

  On the other hand, when there is no valid mapping information corresponding to the device ID of the old device received together with the mapping change request (step S1301: No), or valid mapping information corresponding to the device ID of the new device received together with the mapping change request. If there is (step S1302: Yes), the mapping management unit 15 responds with a mapping change NG to the device validity management unit 14 (step S1306), and ends the mapping change process.

  FIG. 37 is a sequence diagram illustrating an operation example of the replacement registration process including the mapping change process. The sequence diagram of FIG. 37 shows an operation example of the request accepting unit 11, the device validity management unit 14 and the mapping management unit 15 in response to a replacement registration request by a user (an operation example when replacement registration is successful). Yes.

  The replacement registration request by the user is received by the request receiving unit 11 (step S1401). The replacement registration request received by the request receiving unit 11 is sent from the request receiving unit 11 to the device validity management unit 14 (step S1402). In this replacement registration request, the device name and installation location of the old device and the device ID of the new device are added.

  Upon receiving the replacement registration request from the request reception unit 11, the device validity management unit 14 requests the mapping management unit 15 to change the mapping (step S1403). In this mapping change request, the device ID of the old device and the device ID of the new device are added. Upon receiving the mapping change request from the device validity management unit 14, the mapping management unit 15 invalidates the mapping information corresponding to the device ID of the old device and generates mapping information corresponding to the device ID of the new device. Registration is performed (step S1404). Then, the mapping management unit 15 responds to the device validity management unit 14 with the mapping change result of the change OK (step S1405).

  Upon receipt of the change OK mapping change result from the mapping management unit 15, the device validity management unit 14 invalidates the validity management information corresponding to the old device and generates the validity management information corresponding to the new device. (Step S1406). Then, the device validity management unit 14 notifies the request reception unit 11 of the replacement registration result of replacement OK (step S1407). Upon receiving the replacement registration result of replacement OK from the device validity management unit 14, the request reception unit 11 notifies the user of completion of replacement registration (step S1408).

  FIG. 38 is a flowchart illustrating an operation example of the setting change process. The series of processing shown in the flowchart of FIG. 38 is processing executed when the setting management unit 16 receives a setting change request from the request receiving unit 11.

  When receiving a setting change request from the request receiving unit 11, the setting management unit 16 first acquires setting information associated with the device ID received together with the setting change request (step S1501). Then, the setting management unit 16 changes the setting information acquired in step S1501 based on the change contents received together with the setting change request (step S1502), and ends the setting change process. The setting information changed in this way is reflected in the device 20 by setting synchronization processing described later.

  FIG. 39 is a flowchart illustrating an operation example of setting synchronization processing in the device 20. The series of processes shown in the flowchart of FIG. 39 is a process that the setting synchronization unit 23 of the device 20 executes regularly or at a predetermined timing.

  When performing the setting synchronization processing, the setting synchronization unit 23 of the device 20 first requests setting information from the device management apparatus 10 (step S1601), and the setting information transmitted from the device management apparatus 10 as a response to this request. Is received (step S1602). Then, the setting synchronization unit 23 compares the setting information received in step S1602 with the setting information held by the device 20 (step S1603). The setting information held by the device 20 represents the current setting of the device 20.

  If there is a difference between the setting information received from the device management apparatus 10 and the setting information held by the device 20 as a result of the comparison in step S1603 (step S1604: Yes), the setting synchronization unit 23 uses the difference as the device. The setting information held in the device 20 is updated (step S1605), and the setting synchronization processing is terminated. On the other hand, if there is no difference between the setting information received from the device management apparatus 10 and the setting information held by the device 20 (step S1604: No), the setting synchronization processing is terminated as it is.

  FIG. 40 is a flowchart illustrating an operation example of setting synchronization processing in the device management apparatus 10. The series of processing shown in the flowchart of FIG. 40 is processing executed when the setting management unit 16 of the device management apparatus 10 receives a setting information request from the device 20.

  When receiving the setting information request from the device 20, the setting management unit 16 of the device management apparatus 10 checks whether there is setting information associated with the received device ID along with the setting information request (step S1701). If there is setting information associated with the received device ID (step S1701: Yes), the setting information associated with this device ID is transmitted to the device 20 (step S1702), and the setting synchronization processing is terminated.

  On the other hand, when there is no setting information associated with the received device ID (step S1701: No), the setting management unit 16 requests the device ID of the old device from the mapping management unit 15 (step S1703). That is, the setting management unit 16 holds the setting information of the device 20 in the installed state. However, when the old device is replaced with the new device by the replacement of the device 20 described above, the setting management unit 16 holds It is the setting information of the old device and does not hold the setting information of the new device. Therefore, the setting management unit 16 requests the device ID of the old device from the mapping management unit 15 in order to specify the setting information of the old device.

  When the device ID of the old device is sent from the mapping management unit 15, the setting management unit 16 acquires the device ID of the old device (step S1704), and sets the setting information associated with the device ID of the old device as the new device ID. It is associated with the device ID of the device, that is, the device ID received from the device 20 together with the request for setting information (step S1705). Then, the setting information whose association has been changed so as to be associated with the device ID of the new device is transmitted to the requesting device 20 (step S1706), and the setting synchronization processing ends.

  FIG. 41 is a flowchart illustrating an operation example of the old device ID search process. The series of processing shown in the flowchart of FIG. 41 is processing executed when the mapping management unit 15 receives a request for the device ID of the old device from the setting management unit 16.

  When receiving the request for the device ID of the old device from the setting management unit 16, the mapping management unit 15 first identifies valid mapping information corresponding to the received device ID (step S1801). Next, the mapping management unit 15 acquires the start date and time of the mapping information specified in step S1801 (step S1802), and specifies invalid mapping information including an end date and time that matches the acquired start date and time (step S1803). The mapping management unit 15 transmits the device ID included in the mapping information identified in step S1803 as the device ID of the old device to the requesting device 20 (step S1804), and ends the old device ID search process. When the device 20 is replaced by the setting synchronization processing including the above old device ID search processing, the user can take over the setting information of the old device as the setting information of the new device without performing any special operation. Can be made.

  FIG. 42 is a sequence diagram illustrating an operation example of the history information accumulation process. The sequence diagram of FIG. 42 shows a usage history management unit 17, a service management unit 13, a user management unit 12 and mapping when a job such as printing or scanning is executed in the device 20 and log information related to the job is transmitted. An operation example of the management unit 15 is shown.

  The log information transmitted from the device 20 is received by the usage history management unit 17 of the device management apparatus 10 (step S1901). This log information includes a device ID, a log type, and a usage amount. When receiving the log information from the device 20, the usage history management unit 17 requests the service management unit 13 to acquire the service ID in order to acquire the service ID corresponding to the device 20 that transmitted the log information ( Step S1902). In this service ID acquisition request, the device ID of the device 20 that transmitted the log information is added.

  When the service management unit 13 receives the service ID acquisition request from the usage history management unit 17, the service management unit 13 asks the user management unit 12 to acquire a user ID associated with the service ID requested by the usage history management unit 17. The user ID is requested to be acquired (step S1903). The device ID of the device 20 that transmitted the log information is added to this user ID acquisition request.

  Upon receiving the user ID acquisition request from the service management unit 13, the user management unit 12 sends a mapping ID associated with the user ID requested by the user management unit 12 to the mapping management unit 15. The acquisition of the mapping ID is requested (step S1904). The device ID of the device 20 that transmitted the log information is added to this mapping ID acquisition request.

  When receiving the mapping ID acquisition request from the user management unit 12, the mapping management unit 15 searches the mapping information for a mapping ID associated with the device ID of the device 20 that has transmitted the log information (step S1905). Then, the acquired mapping ID is returned to the user management unit 12 (step S1906).

  When receiving the mapping ID from the mapping management unit 15, the user management unit 12 searches the user information for the user ID associated with the mapping ID received from the mapping management unit 15 (step S1907). Then, the acquired user ID is returned to the service management unit 13 (step S1908).

  When the service management unit 13 receives the user ID from the user management unit 12, the service management unit 13 searches the service management information for a service ID associated with the user ID received from the user management unit 12 (step S1909). . Then, the acquired service ID is returned to the usage history management unit 17 (step S1910).

  When receiving the service ID from the service management unit 13, the usage history management unit 17 stores the log information received from the device 20 as history information in association with the service ID received from the service management unit 13 (step S1911). Through the above history information accumulation processing, the usage history management unit 17 manages the usage history of services such as printing and scanning performed using the device 20 not for each device 20 but for each service purchased by the user. Can do. Even when the device 20 is replaced, the association between the device ID of the old device and the service ID is associated with the service ID of the new device via the mapping ID and the user ID. As a result, it is possible to calculate the usage amount consistently between the old and new devices.

  FIG. 43 is a flowchart illustrating an operation example of the usage amount totaling process. The process shown in the flowchart of FIG. 43 is a process executed when the usage history management unit 17 receives a usage amount totaling request from the request reception unit 11.

  When receiving the usage amount totaling request from the request receiving unit 11, the usage history managing unit 17 first acquires all historical information associated with the service ID received together with the usage amount totaling request, and includes the usage amount included in the historical information. (Step S2001). Then, the usage history management unit 17 responds to the request reception unit 11 with the total usage amount (step S2002). The usage amount totaling result is displayed so as to be viewable by the user on the above-described usage amount totaling screen SC700 (see FIG. 22).

  In the present embodiment, it is assumed that the usage history management unit 17 retains only history information within a period to be charged (for example, for the current month) and deletes history information of a service for which charging processing has ended. However, the usage history management unit 17 may also hold the history information of the service for which the accounting process has been completed. In this case, the usage history management unit 17 may collect the history information and aggregate the usage amount within the period when the usage amount totaling request is received.

  FIG. 44 is a flowchart illustrating an operation example of device state list generation processing. The series of processing shown in the flowchart of FIG. 44 is processing that is executed when the state management unit 18 receives a device state list request from the request reception unit 11.

  When the status management unit 18 receives the device status list request from the request reception unit 11, the status management unit 18 first requests the user management unit 12 for all mapping IDs associated with the user ID received together with the device status list request. (Step S2101). Then, the mapping ID sent from the user management unit 12 as a response to this request is acquired (step S2102).

  Next, the state management unit 18 requests the mapping management unit 15 for all device IDs associated with the mapping ID acquired in step S2102 (step S2103). Then, the device ID sent from the mapping manager 15 as a response to this request is acquired (step S2104).

  Then, the state management unit 18 collects the state information of the device 20 associated with the device ID acquired in step S2104, and responds to the request reception unit 11 with the collected state information (step S2105). The state information collected by the state management unit 18 is displayed so as to be viewable by the user on the above-described device state list screen SC800 (see FIG. 23).

<Effect of embodiment>
As described above in detail with specific examples, in the device management system 1 according to the present embodiment, the device management apparatus 10 is a mapping ID that is management identification information having a logical history for managing the device 20. And the device ID for identifying the individual device 20 is associated with this mapping ID. When the device 20 that is regarded as the same in the user's cognitive identification is replaced with the new device by replacing the device 20, the device ID associated with the mapping ID is changed from the device ID of the old device to the new device. The device ID is changed. Therefore, according to the present embodiment, it is possible to treat the devices 20 regarded as the same by the user's cognitive identification as the same, and to reduce the management effort.

  For example, when the device 20 is replaced, the relationship between the old device and the new device is known based on the mapping ID, so that the user can set the old device setting information without performing any special operation. It can be inherited as setting information.

  Even when the device 20 is replaced, the association between the device ID of the old device and the service ID is associated with the service ID of the new device via the mapping ID and the user ID. As a result, it is possible to calculate the usage amount consistently between the old and new devices.

<Supplementary explanation>
The functional components described above of the device management apparatus 10 according to the present embodiment include, as an example, hardware as a general computer illustrated in FIG. 2 and a program (software) executed using the hardware. Can be realized through collaboration with In this case, a program for realizing functional components of the device management apparatus 10 can be provided by being incorporated in advance in the ROM 103 or the nonvolatile memory 104 in the device management apparatus 10, for example. The program is recorded in a computer-readable recording medium such as a CD-ROM, a flexible disk (FD), a CD-R, and a DVD (Digital Versatile Disc) in a file in an installable or executable format. May be provided.

  Alternatively, the program may be stored on another computer connected to the network 40 and provided by being downloaded to the device management apparatus 10 via the network. These programs may be configured to be provided or distributed via the network 40.

  The program executed by the device management apparatus 10 includes, for example, the above-described functional components of the device management apparatus 10 (request receiving unit 11, user management unit 12, service management unit 13, device validity management unit 14, The module configuration includes program components corresponding to the mapping management unit 15, the setting management unit 16, the usage history management unit 17, and the state management unit 18). As the actual hardware, for example, when the CPU 101 reads out and executes this program from the ROM 103 or the nonvolatile memory 104, these functional components are loaded on the main storage unit such as the RAM 102, and these Functional components are generated on the main storage unit.

  In the case where the device management apparatus 10 is realized by a combination of a plurality of computers, a program corresponding to a functional component realized by the computer may be provided for each computer. In addition, the above-described functional components of the device management apparatus 10 are partially or entirely realized using dedicated hardware such as an application specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). It is also possible.

[Second Embodiment]
Next, a second embodiment will be described. In the present embodiment, specific realization means for performing settings such as acquisition of information managed by the device management apparatus 10 and use restriction will be exemplified. In the first embodiment described above, it has been described that the user of the device management system 1 can make various requests to the device management apparatus 10 using the management terminal 30 or the like. Web API (Web Application Programming Interface) technology is used as a specific means for accepting a setting request such as a usage restriction in the device management apparatus 10. That is, in the present embodiment, the request reception unit 11 of the device management apparatus 10 has a Web API, and various requests to the device management apparatus 10 are received via the network 40 by this Web API.

  In the present embodiment, for example, counter information (various counter values) indicating the usage frequency of the device 20 or device cooperation service managed by the device management apparatus 10, the device 20, or the device through the Web API prepared in the device management apparatus 10. Use restriction information indicating the setting contents of use restrictions (upper limit values for various counters) for linked services can be acquired. In the present embodiment, use restrictions on the device 20 and the device cooperation service can be arbitrarily set through the Web API prepared in the device management apparatus 10. Note that information that can be acquired from the device management apparatus 10 through the Web API is not limited to the above-described counter information and use restriction information, and various information managed by the device management apparatus 10 can be acquired. For example, in the above-described first embodiment, as an example of information that the user acquires from the device management apparatus 10 using the management terminal 30, a service usage amount totaling result, a list of the state of the device 20, and the like are illustrated. However, such information can also be acquired through WebAPI. In addition, the settings performed through the Web API are not limited to the above-described usage restrictions, and various settings managed by the device management apparatus 10 can be targeted. For example, in the first embodiment described above, a mechanism has been described in which a user can perform printer settings, scanner settings, and the like of the device 20 using the management terminal 30, but such settings of the device 20 can also be performed through the Web API. It is.

  Here, the device cooperation service assumed in this embodiment will be described. The device cooperation service is a service realized by cooperation between the device management apparatus 10 configured as a cloud server and the device 20, for example. Examples of such services include a cloud scan service and a cloud print service. The cloud scan service is a service that stores image data scanned by the device 20 and transferred to the cloud (device management apparatus 10) side in a predetermined storage or distributed to a predetermined distribution destination. The cloud print service is a service that causes the device 20 to download print data uploaded in advance to the cloud (device management apparatus 10) side and cause the device 20 to execute a print job based on the print data. Applications that realize such a device cooperation service are installed on the device management apparatus 10 side, and the device cooperation service is executed when a user uses these applications through a browser.

  In the present embodiment, it is assumed that users of the device management system 1 form a group. For example, in the office environment, the group can be set according to the job classification, such as a group of XX department XX section. FIG. 45 is a diagram showing a data model of a management unit assumed in the present embodiment, and shows the relationship between a group and users, applications, and devices 20 belonging to the group in a format in UML (Unified Modeling Language). is there. Note that “application” in FIG. 45 represents an application for realizing the above-described device cooperation service, and “function” connected to “application” is a function realized by the application (cloud scan service, cloud print service, etc.) Represents. In FIG. 45, “device” represents the device 20 managed by the device management apparatus 10, and “function” connected to “device” represents a function (mainly copy, print, Scanner, FAX, etc.). In the present embodiment, as shown in FIG. 45, it is assumed that users, apps, and devices are grouped together according to the concept of groups. That is, each of a user, an application, and a device is associated through a group, and users belonging to the same group can use a common application, a common device 20, and the function thereof.

In the present embodiment, as an example, a description will be given of a mechanism in which an external device such as the management terminal 30 acquires the following counter information (1) to (3) from the device management device 10 and restricts the use by an arbitrary number. .
(1) Counter value for each function (copy, print, scanner, FAX) and user for each device 20 belonging to a certain group (2) Total function value for each device 20 belonging to a certain group and counter value for each user (3) Counter value for each function and user for each application belonging to a certain group Note that the counter information of (1) is information that the device management apparatus 10 collects and holds / manages from the device 20 at a predetermined timing. It is. The counter information (2) is information that the device management apparatus 10 tabulates based on the information (1) and holds / manages it. The counter information (3) is information that the device management apparatus 10 aggregates, holds and manages according to the use of the device cooperation service. Since the use of the device cooperation service is also counted in the device 20, the counter information in (1) includes a count overlapping with the counter information in (3).

  Hereinafter, a specific configuration example and an operation example of the device management system of the present embodiment will be described. In this embodiment, the same components as those in the first embodiment are denoted by the same reference numerals, and the prime (dash) symbol “′” is used for the components corresponding to the components in the first embodiment. The same reference numerals distinguished from each other will be given, and redundant description will be omitted as appropriate.

  FIG. 46 is a system configuration diagram showing an overview of the device management system 1 ′ of this embodiment. In the device management system 1 ′ of the present embodiment, in addition to the device 20 and the management terminal 30, a user terminal 50 for a user to access an application of the device management apparatus 10 ′ in order to use the device cooperation service described above. Are communicably connected to the device management apparatus 10 ′ via the network 40. As the user terminal 50, an information processing apparatus such as a PC, a tablet terminal, or a smartphone equipped with a web browser can be used.

  In the present embodiment, when a user uses the device cooperation service, the user terminal 50 is used to access the device management apparatus 10 ′, specify an application to be used, and request execution reservation of the device cooperation service. In the device management apparatus 10 ', execution reservation of the device cooperation service by the application specified in response to the request from the user is performed, reservation information such as a pin code is issued, and this reservation information is used as a response to the request. To the person terminal 50. After that, the user inputs reservation information such as a pin code to the device 20 used for the device cooperation service, and uses the application specified at the time of request for execution reservation, so that the cloud scan service or cloud print corresponding to this application is used. The service is executed. At this time, the device management apparatus 10 ′ counts the number of job executions of the device cooperation service according to the application as a use history of the application by the user, and holds it as a counter value.

  FIG. 47 is a block diagram illustrating a functional configuration example of the device management apparatus 10 ′ of the present embodiment. For example, as illustrated in FIG. 47, the device management apparatus 10 ′ includes a request reception unit 11 ′ as a functional component realized by the cooperation of hardware and software (program) similar to those in the first embodiment. A user management unit 12 ′, a service management unit 13, a device validity management unit 14, a mapping management unit 15, a setting management unit 16 ′, a usage history management unit 17 ′, and a state management unit 18. A job management unit 19. Among these, the service management unit 13, the device validity management unit 14, the mapping management unit 15, and the state management unit 18 are the same components as those in the first embodiment described above, and thus the description thereof is omitted.

  In addition to the function of the request receiving unit 11 of the first embodiment, the request receiving unit 11 ′ sends various requests to the user device management apparatus 10 ′ using the management terminal 30, the user terminal 50, and the like through WebAPI. Has a function to accept. In the present embodiment, the function of the device management apparatus 10 ′ is disclosed on the network 40 because the request receiving unit 11 ′ has a Web API. When various requests to the device management apparatus 10 'are transmitted from the management terminal 30 or the user terminal 50 through the network 40 in the form of an HTTP request, the response to the request is managed from the device management apparatus 10' in the form of an HTTP response. It is transmitted to the terminal 30 and the user terminal 50.

  FIG. 48 is a diagram for explaining the outline of the request receiving unit 11 ′. For example, as illustrated in FIG. 48, the request reception unit 11 ′ has three types of Web APIs: a job API 61, an authentication API 62, and a management API 63. The job API 61 is a Web API that accepts an execution reservation for the device cooperation service from the user terminal 50 and returns reservation information such as a pin code. The authentication API 62 is a Web API that receives a login request from the user terminal 50 or the management terminal 30 and returns an authentication result. The management API 63 receives an acquisition request for counter information, usage restriction information, etc., a usage restriction setting request from the management terminal 30, and if it is an information acquisition request, the information is set if it is a setting request for usage restrictions. This is a Web API that returns a notification of completion. In the present embodiment, the management terminal 30 is equipped with a Web browser, and the management terminal 30 makes an information acquisition request, a usage restriction setting request, and the like to the device management apparatus 10 ′. However, various requests to the device management apparatus 10 ′ can be made not only from the management terminal 30 but also from various information processing apparatuses equipped with a Web browser connected to the network 40.

  Similar to the user management unit 12 of the first embodiment, the user management unit 12 ′ has a function of holding and managing user information using the user management table T1 as shown in FIG. It has a function to hold and manage group information related to user groups. FIG. 49 is a diagram illustrating an example of a data structure of group information held by the user management unit 12 ′. The group information includes a group ID for identifying a group, a user ID of a user belonging to the group, an application ID for identifying an application of a device cooperation service that can be used by a user belonging to the group, and the group information. This is information that associates the mapping ID corresponding to the device 20 that can be used by the user. For example, as shown in FIG. 49, this group information is registered and held in a group management table T10 constructed in the nonvolatile memory 104 or the like.

  In this embodiment, the user management unit 12 ′ holds and manages the user information and the group information as separate information. For example, the group ID and application ID are stored in the user management table T1 in FIG. For example, a user information and group information may be held and managed as integrated information, such as by adding a column for storing.

  Similar to the usage history management unit 17 of the first embodiment, the usage history management unit 17 ′ stores and manages the log information collected from the device 20 as history information, and holds the above-described counter information for each group.・ Has a function to manage. The counter information for each group includes the counter values of the counter information (1), the counter values of the counter information (2), and the counter values of the counter information (3).

  FIG. 50 is a diagram illustrating an example of the data structure of the counter information, and illustrates an example of the counter information related to the group (see FIG. 49) whose group ID is “12345”. For example, as shown in FIG. 50, the counter information is registered and held in counter tables T11_1 to T11_5 constructed in the nonvolatile memory 104 or the like in units of groups.

  The counter table T11_1 in FIG. 50A and the counter table T11_2 in FIG. 50B indicate counter values for each device 20 belonging to the group having the group ID “12345”. That is, the counter table T11_1 in FIG. 50A indicates the counter value of the device 20 (device 20 whose device ID is “AB123456”) corresponding to the mapping ID “11” illustrated in FIG. Further, the counter table T11_2 of FIG. 50B shows the counter value of the device 20 (device 20 whose device ID is “CD1357246”) corresponding to the mapping ID “12” shown in FIG. The counter values for each device 20 indicated by these counter tables correspond to the counter information (1).

  In the present embodiment, each of the devices 20 managed by the device management apparatus 10 ′ counts the number of job executions as a usage history of the device 20 by the user, and holds it as a counter value for each function and each user. Shall. Each device 20 transmits the counter value held by itself at a predetermined timing to the device management apparatus 10 '. The usage history management unit 17 ′ of the device management apparatus 10 ′ sets the counter value thus transmitted from each device 20 at a predetermined timing for each device 20 as shown in FIG. 50 (a) or FIG. 50 (b). To the counter table. It should be noted that the total counter value for each user and the total counter value for each function may be a value aggregated in each device 20 or a value aggregated by the usage history management unit 17 ′ of the device management apparatus 10 ′. May be. Further, the timing at which each device 20 transmits the counter value to the device management apparatus 10 ′ may be each time a job is executed as in the case of transmission of log information in the first embodiment, or the activation of the device 20 It may be a form that is periodically transmitted every predetermined time after time and activation, or a combination thereof. Further, identification of the user in the device 20 can be realized, for example, when the user performs a login process on the operation panel of the device 20 when executing a job.

  The counter table T11_3 in FIG. 50C shows the total counter values of the devices 20 belonging to the group whose group ID is “12345”. The counter value of the counter table T11_3 is a value that is aggregated by the usage history management unit 17 ′ based on the counter value of the counter table T11_1 in FIG. 50A and the counter value of the counter table T11_2 in FIG. And corresponds to the counter information of (2) above.

  The counter table T11_4 in FIG. 50D and the counter table T11_5 in FIG. 50E indicate counter values for each application belonging to the group having the group ID “12345”. That is, the counter table T11_4 in FIG. 50D shows counter values representing the usage history of the application (see FIG. 49) whose application ID is “APP7777”. Further, the counter table T11_5 in FIG. 50E shows counter values representing the use history of the application (see FIG. 49) whose application ID is “APP6666”. The counter values for each application indicated by these counter tables correspond to the counter information (3) above.

  When the request reception unit 11 ′ receives a counter information acquisition request from the management terminal 30, the usage history management unit 17 ′ reads counter information corresponding to the group specified by the acquisition request from the nonvolatile memory 104 or the like. To the request receiving unit 11 ′. Thereby, the request reception unit 11 ′ can return counter information corresponding to the designated group to the management terminal 30 as a response to the acquisition request from the management terminal 30.

  The setting management unit 16 ′, in addition to the function of holding and managing setting information such as printer settings and scanner settings for each device 20, in the same manner as the setting management unit 16 of the first embodiment, It has a function to maintain and manage each. The usage restriction information for each group includes an upper limit value set for each counter of the counter information in (1), an upper limit value set for each counter in the counter information in (2), And the upper limit value set for each counter in the counter information of (3) above.

  FIG. 51 is a diagram showing an example of the data structure of the usage restriction information, and shows the setting contents of usage restrictions (the upper limit value of the counter) set for each counter of the counter information exemplified in FIG. In addition, the numerical value in a figure shows the upper limit of a counter, "-1" has shown that the use restriction is not set. For example, as shown in FIG. 51, the use restriction information is registered and held in use restriction tables T12_1 to T12_5 constructed in the nonvolatile memory 104 or the like in units of groups.

  The usage restriction table T12_1 in FIG. 51A is an example of usage restriction information corresponding to the counter table T11_1 shown in FIG. 50A, and the usage set for the device 20 whose device ID is “AB123456”. Indicates the content of the restriction. The usage restriction table T12_2 in FIG. 51B is an example of usage restriction information corresponding to the counter table T11_2 shown in FIG. 50B, and is set for the device 20 whose device ID is “CD1357246”. The contents of usage restrictions are shown. The usage restriction information set for each device 20 is reflected in the setting of each device 20 by the above-described setting synchronization process performed between the setting management unit 16 ′ and the device 20.

  The usage restriction table T12_3 in FIG. 51C is an example of usage restriction information corresponding to the counter table T11_3 shown in FIG. 50C, and the total usage of the devices 20 belonging to the group whose group ID is “12345”. Indicates the content of the restriction. Further, the usage restriction table T12_4 in FIG. 51D is an example of usage restriction information corresponding to the counter table T11_4 shown in FIG. 50D, and is set for an application whose application ID is “APP7777”. Indicates the contents of usage restrictions. Further, the usage restriction table T12_5 in FIG. 51 (e) is an example of usage restriction information corresponding to the counter table T11_5 shown in FIG. 50 (e), and is set for an application whose application ID is “APP6666”. Indicates the contents of usage restrictions.

  Usage restrictions on the device 20 and the device cooperation service can be implemented based on the above-described counter information held and managed by the usage history management unit 17 ′ and the usage restriction information held and managed by the setting management unit 16 ′. . That is, the remaining number that can be used is calculated as needed from the current various counter values and the upper limit value, and the use of the device 20 and the device cooperation service is restricted so that the counter value does not exceed the upper limit value.

  In the present embodiment, as shown in the use restriction tables T12_1 to T12_5 in FIG. 51, the use restrictions for each function and for each user can be set for each device 20 belonging to a certain group, for the total of the devices 20, and for each application. I am doing so. It is also possible to set a total usage restriction for each user and a total usage restriction for each function. By setting the total use restriction for each user, the total amount of use of the device 20 or application by a certain user can be restricted, and by setting the total use restriction for each function, The total usage of functions and application functions can be limited. For example, in the use restriction table T12_1 in FIG. 51A, no use restriction is set for the “FAX” function, but for each of “User 1” to “User 3”, a total for each user is set. Since the counter upper limit value is set to “11,000”, the use of the “FAX” function is restricted so that the sum of the counter values of other functions does not exceed “11,000”. .

  When the request accepting unit 11 ′ accepts an acquisition request for use restriction information from the management terminal 30, the setting management unit 16 ′ sends the use restriction information corresponding to the group designated by the obtainment request from the nonvolatile memory 104 or the like. Read and pass to the request receiving unit 11 ′. Thereby, the request reception unit 11 ′ can return the usage restriction information corresponding to the designated group to the management terminal 30 as a response to the acquisition request from the management terminal 30.

  In addition, when the request receiving unit 11 ′ receives a usage restriction setting request from the management terminal 30, the setting management unit 16 ′ receives the group and setting target category (the above (1) to ( The usage restriction setting in any one of 3) is changed according to the setting request, and the usage restriction information stored as a usage restriction table in the nonvolatile memory 104 or the like is updated, for example. When the use restriction setting change is completed, the request reception unit 11 ′ is notified of the completion of the setting change. As a result, the request receiving unit 11 ′, as a response to the usage restriction setting request from the management terminal 30, sends a setting completion notification indicating that the setting of the usage restriction corresponding to the designated setting target category has been completed. Can be returned to 30.

  The job management unit 19 is a functional module that manages job execution by the above-described device cooperation service. The job management unit 19 issues reservation information such as a pin code and requests the reservation information in response to the request reception unit 11 ′ receiving a request for execution of device cooperation service from the user terminal 50. It passes to reception part 11 '. Thereby, the request reception unit 11 ′ can return reservation information such as a pin code to the user terminal 50 as a response to the request from the user terminal 50.

  In addition, when the job management unit 19 receives reservation information such as a pin code input to the device 20 by the user from the device 20, the job management unit 19 calls an application specified by the reservation information, and performs a cloud scan service or the like corresponding to the application. Controls job execution by the cloud print service. At this time, the job management unit 19 counts the number of job executions of the device cooperation service corresponding to the application, and transmits the count value to the usage history management unit 17 ′. As a result, the usage history management unit 17 ′ can hold and manage the counter information for each application described above.

  As described above, in the device management apparatus 10 ′ of the present embodiment, the request reception unit 11 ′ has a Web API, and various requests to the device management apparatus 10 ′ are received by this Web API. Therefore, it is possible to acquire information from the device management apparatus 10 ′ and perform various settings using an arbitrary management tool. In the following, it is assumed that the management terminal 30 is equipped with a management tool for obtaining the above-described counter information and usage restriction information, setting usage restrictions, etc., and the management tool installed in the management terminal 30 by the user A specific example of the operation performed by the device management apparatus 10 ′ according to the present embodiment will be described on the assumption that the device management device 10 is used.

  FIG. 52 is a diagram illustrating a screen example of the management tool displayed on the display panel 307 of the management terminal 30, and illustrates a screen transition example when setting usage restrictions. The screen shown in FIG. 52A is an example of a login screen SC910 that is first displayed on the display panel 307 of the management terminal 30 or the like. When the user inputs a group ID in the text box 911, a login ID in the text box 912, and a password in the text box 913 on the login screen SC 910 and operates the “Login” button 914, the screen of the management tool is displayed as shown in FIG. A transition is made from the login screen SC910 of 52 (a) to the function selection screen SC920 shown in FIG.

  The function selection screen SC920 shown in FIG. 52B is provided with a “counter information reference” button 921, a “use restriction information reference” button 922, and a “use restriction setting” button 923. By selectively operating these buttons, the user can request the device management apparatus 10 'to obtain the above-described counter information and usage restriction information and to set usage restrictions. Here, it is assumed that the user operates the “use restriction setting” button 923 to set use restriction. When the user operates the “use restriction setting” button 923 on the function selection screen SC920, the management tool screen changes from the function selection screen SC920 in FIG. 52B to the use restriction setting screen SC930 shown in FIG. Transition to.

  The usage restriction setting screen SC930 shown in FIG. 52C is provided with a “group” button 931, an “application” button 932, and a “device” button 933. The user can designate a setting target category by selectively operating these buttons. The setting target category is a category for which usage restriction is set, and is a usage restriction setting for each device 20 in the group, a total usage restriction setting for the devices 20 in the group, or a group. Indicates whether it is a usage restriction setting for each application. When the user designates a setting target category on the use restriction setting screen SC930, the management terminal 30 assigns a group (group ID input on the login screen SC910) and a setting target category to the device management apparatus 10 ′. It is possible to request acquisition of the specified usage restriction information, and as a response, the usage restriction information of the specified group and setting target category can be acquired from the device management apparatus 10 ′.

  FIG. 53 is a diagram showing an example of a setting input screen SC940 displayed when the user operates the “group” button 931 on the usage restriction setting screen SC930 shown in FIG. On this setting input screen SC940, usage restriction information (corresponding to the usage restriction table T12_3 in FIG. 51C) indicating the contents of the total current usage restrictions of the devices 20 in the designated group is displayed in a rewritable manner. A display area 941, a “set” button 942, and a “cancel” button 943 are provided. When the user rewrites the numerical value displayed in the display area 941 on the setting input screen SC940 to a desired numerical value and operates the “setting” button 942, the use restriction on the device management apparatus 10 ′ from the management terminal 30 is performed. The total use restriction of the devices 20 in the group is newly set according to the contents input by the user. If the user operates the “cancel” button 943 on the setting input screen SC940, the processing is interrupted, and for example, the management tool screen returns to the function selection screen SC920 in FIG.

  FIG. 54 is a diagram showing an example of a setting input screen SC950 displayed when the user operates the “app” button 932 on the usage restriction setting screen SC930 shown in FIG. 52 (c). In this setting input screen SC950, usage restriction information indicating the contents of the current usage restrictions for each application in the designated group (usage restriction table T12_4 in FIG. 51D and use restriction table T12_5 in FIG. 51E). Are displayed in a rewritable manner, “set” buttons 952 and 955, and “cancel” buttons 953 and 956. When the user rewrites the numerical values displayed in the display areas 951 and 954 on the setting input screen SC950 to desired numerical values and operates the “setting” buttons 952 and 955, the management terminal 30 changes to the device management apparatus 10 ′. On the other hand, setting of usage restrictions is requested, and usage restrictions for each application in the group are newly set according to the contents input by the user. If the user operates the “cancel” buttons 953 and 956 on the setting input screen SC950, the process is interrupted, and for example, the management tool screen returns to the function selection screen SC920 shown in FIG.

  FIG. 55 is a diagram showing an example of a setting input screen SC960 that is displayed when the user operates the “device” button 933 on the usage restriction setting screen SC930 shown in FIG. In this setting input screen SC960, usage restriction information (usage restriction table T12_1 in FIG. 51A and usage restriction table in FIG. 51B) indicating the contents of the current usage restriction for each device 20 in the specified group. Display areas 961 and 964 that display rewritable, “set” buttons 962 and 965, and “cancel” buttons 963 and 966. When the user rewrites the numerical values displayed in the display areas 961 and 964 on the setting input screen SC960 to desired numerical values and operates the “setting” buttons 962 and 965, the management terminal 30 changes to the device management apparatus 10 ′. On the other hand, setting of usage restrictions is requested, and usage restrictions for each device 20 in the group are newly set according to the contents input by the user. If the user operates the “cancel” buttons 963 and 966 on the setting input screen SC960, the processing is interrupted, and for example, the management tool screen returns to the function selection screen SC920 shown in FIG.

  FIG. 56 is a sequence diagram illustrating an operation example in response to a counter information acquisition request. First, when the user performs a login operation from the management tool login screen SC910 (step S2201), a login request is sent from the management terminal 30 to the device management apparatus 10 ′, and the login request is sent to the request reception unit 11 ′. (Step S2202). A group ID, a login ID, and a password input by the user are added to the login request. The login request received by the request receiving unit 11 'is sent from the request receiving unit 11' to the user management unit 12 '(step S2203).

  Upon receiving the login request from the request receiving unit 11 ′, the user management unit 12 ′ performs an authentication process for the user based on the login ID and password added to the login request (step S 2204). Then, the user management unit 12 'returns an authentication result to the request reception unit 11' (step S2205). Here, it is assumed that the authentication result is authentication OK. The user ID of the user who is authenticated is added to the authentication result of the authentication OK. Upon receiving the authentication OK authentication result from the user management unit 12 ′, the request reception unit 11 ′ sends an authentication token to the management terminal 30 (step S 2206).

  Thereafter, when the user operates the “reference counter information” button 921 on the function selection screen SC920 of the management tool (step S2207), a request for obtaining counter information is sent from the management terminal 30 to the device management apparatus 10 ′. The counter information acquisition request is received by the request receiving unit 11 ′ (step S2208). In this counter information acquisition request, an authentication token and, for example, a group ID input by the user during a login operation are added. The counter information acquisition request received by the request receiving unit 11 'is sent from the request receiving unit 11' to the usage history management unit 17 '(step S2209).

  Upon receiving the counter information acquisition request from the request reception unit 11 ′, the usage history management unit 17 ′ acquires the counter information of the specified group based on the group ID added to the counter information acquisition request. (Step S2210), the acquired counter information is sent to the request receiving unit 11 ′ (step S2211). Upon receiving the counter information from the usage history management unit 17 ′, the request reception unit 11 ′ sends this counter information to the management terminal 30 as a response to the acquisition request (step S 2212). Then, the management terminal 30 displays the counter information received from the request receiving unit 11 'as a response to the acquisition request (step S2213). Thereby, the user can refer to the counter information of the group identified by the group ID input at the time of login operation, for example.

  FIG. 57-1 is a diagram illustrating a data example of a counter information acquisition request sent from the management terminal 30 to the device management apparatus 10 ′, and FIG. 57-2 is a response data to the acquisition request illustrated in FIG. 57-1. It is a figure which shows an example. The management terminal 30 is described in the HTTP response format as shown in FIG. 57-2, for example, by sending a counter information acquisition request to the device management apparatus 10 ′ as an HTTP request as shown in FIG. Counter information can be received. In FIG. 57-2, “...” Indicates that some of the descriptions are omitted.

  FIG. 58 is a sequence diagram illustrating an operation example according to the usage restriction information acquisition request. Note that the processing in steps S2301 to S2306 in FIG. 58 (authentication processing corresponding to the login operation) is the same as the processing in steps S2201 to S2206 in FIG.

  After the authentication process corresponding to the login operation is completed, when the user operates the “use restriction information reference” button 922 on the function selection screen SC920 of the management tool (step S2307), the management terminal 30 changes to the device management apparatus 10 ′. On the other hand, a use restriction information acquisition request is sent, and this use restriction information acquisition request is received by the request receiving unit 11 ′ (step S2308). In this usage restriction information acquisition request, an authentication token and, for example, a group ID input by the user during a login operation are added. The usage restriction information acquisition request received by the request receiving unit 11 'is sent from the request receiving unit 11' to the setting management unit 16 '(step S2309).

  When the setting management unit 16 ′ receives the usage restriction information acquisition request from the request receiving unit 11 ′, the setting management unit 16 ′ obtains the usage restriction information of the specified group based on the group ID added to the usage restriction information acquisition request. Acquired (step S2310) and sends the acquired usage restriction information to the request accepting unit 11 ′ (step S2311). When receiving the usage restriction information from the setting management unit 16 ′, the request receiving unit 11 ′ sends the usage restriction information to the management terminal 30 as a response to the acquisition request (step S 2312). Then, the management terminal 30 displays the usage restriction information received from the request accepting unit 11 'as a response to the acquisition request (step S2313). Thereby, the user can refer to the use restriction information indicating the contents of the use restriction currently set for the group identified by the group ID input at the time of the login operation, for example.

  FIG. 59-1 is a diagram showing an example of data on the usage restriction information acquisition request sent from the management terminal 30 to the device management apparatus 10 ′. FIG. 59-2 shows a response to the acquisition request shown in FIG. It is a figure which shows the example of data. The management terminal 30 sends a usage restriction information acquisition request to the device management apparatus 10 ′ as an HTTP request as shown in FIG. 59-1, for example, and describes in the HTTP response format as shown in FIG. 59-2, for example. Use restriction information can be received. In FIG. 59-2, “...” Indicates that some of the descriptions are omitted.

  FIG. 60 is a sequence diagram illustrating an operation example in response to a usage restriction setting request. 60 are the same as the processes in steps S2201 to S2206 in FIG. 56 and steps S2301 to S2306 in FIG. Omitted.

  After the authentication process corresponding to the login operation is completed, the user operates the “use restriction setting” button 923 on the function selection screen SC920 of the management tool, and further specifies the setting target category on the use restriction setting screen SC930. (Step S2407), first, in order to display the current use restriction information of the designated setting target category on the management terminal 30, the management terminal 30 requests the device management apparatus 10 ′ to obtain use restriction information. Is received, and the request for acquiring the usage restriction information is received by the request receiving unit 11 ′ (step S2408). An authentication token, a group ID, and a setting target category are added to the use restriction information acquisition request. The usage restriction information acquisition request received by the request receiving unit 11 'is sent from the request receiving unit 11' to the setting management unit 16 '(step S2409).

  Upon receiving the use restriction information acquisition request from the request receiving unit 11 ′, the setting management unit 16 ′ receives the specified group and the setting target category based on the group ID and the setting target category added to the use restriction information acquisition request. The usage restriction information of the setting target category is acquired (step S2410), and the acquired usage restriction information is sent to the request receiving unit 11 ′ (step S2411). When receiving the usage restriction information from the setting management unit 16 ′, the request receiving unit 11 ′ sends the usage restriction information to the management terminal 30 as a response to the acquisition request (step S 2412). Then, the management terminal 30 uses the usage restriction information received from the request receiving unit 11 ′ as a response to the acquisition request, and displays the management tool setting input screen (setting input screen SC940 in FIG. 53, setting input screen SC950 in FIG. 54, FIG. 55). Of the setting input screen SC960) is displayed in a rewritable manner (step S2413).

  Thereafter, when the user makes an input for setting usage restrictions on the setting input screen of the management tool (step S2415), a usage restriction setting request is sent from the management terminal 30 to the device management apparatus 10 ′. The use restriction setting request is received by the request receiving unit 11 ′ (step S2416). This usage restriction setting request includes an authentication token, a group ID, a setting target category, and setting contents input by the user. The use restriction setting request received by the request receiving unit 11 'is sent from the request receiving unit 11' to the setting management unit 16 '(step S2417).

  Upon receiving the usage restriction setting request from the request receiving unit 11 ′, the setting management unit 16 ′, based on the group ID and the setting target category added to the usage restriction setting request, specifies the specified group and setting target. The category is specified, and the usage restriction information of the specified group and the setting target category is updated according to the setting contents added to the usage restriction setting request (step S2418). Then, when the update of the usage restriction information is completed, that is, when the setting of a new usage restriction according to the user's setting input is completed, the setting management unit 16 ′ notifies the request reception unit 11 ′ of the completion of setting ( Step 2419). Upon receiving the notification of completion of use restriction setting from the setting management unit 16 ′, the request receiving unit 11 ′ notifies the management terminal 30 of the completion of setting as a response to the use restriction setting request (step S 2420). Then, the management terminal 30 that has received the notification of setting completion displays, for example, a message indicating that the setting according to the input has been completed (step S2421).

  61A is a diagram illustrating a data example of a usage restriction setting request, and FIG. 61B is a diagram illustrating a data example of a response to the usage restriction setting request. The management terminal 30 instructs the device management apparatus 10 ′ to set use restrictions by sending a use restriction setting request to the device management apparatus 10 ′ as, for example, an HTTP request as shown in FIG. Can do. When the use restriction setting is completed, for example, a completion notification described in the HTTP response format shown in FIG. 61-2 can be received. FIG. 61-1 shows an example of a use restriction setting request when “apparatus” indicating the use restriction setting for each device 20 is selected as the setting target category. "..." indicates that some of the descriptions are omitted.

  As described above in detail with reference to specific examples, in the device management apparatus 10 ′ of the present embodiment, the request reception unit 11 ′ has a Web API, and various Web management APIs 10 ′ are provided by this Web API. The request is accepted. Accordingly, information can be acquired from the device management apparatus 10 ′ and various settings can be performed using an arbitrary management tool, and management functions can be easily developed independently from the device management apparatus 10 ′. It becomes.

  Although specific embodiments of the present invention have been described above, the above-described embodiments show an application example of the present invention. The present invention is not limited to the above-described embodiment as it is, and can be embodied with various modifications and changes without departing from the scope of the invention in the implementation stage. For example, some of the constituent elements shown in the above-described embodiment may be modified or deleted, or a plurality of constituent elements disclosed in the above-described embodiment may be appropriately combined. You may implement.

1 (1 ′) Device management system 10 (10 ′) Device management apparatus 11 (11 ′) Request reception unit 12 (12 ′) User management unit 13 Service management unit 14 Device validity management unit 15 Mapping management unit 16 (16 ') Setting management unit 17 (17') Usage history management unit 18 Status management unit 19 Job management unit 20 Device 21 Status transmission unit 22 Log transmission unit 23 Setting synchronization unit 24 Display unit 25 Request transmission unit 30 Management terminal 31 Display unit 32 Request transmission part 40 Network 50 User terminal 61 Job API
62 Authentication API
63 Management API

Japanese Patent No. 5560756 Japanese Patent No. 5434470 JP 2005-234622 A

Claims (15)

A mapping management unit that issues management identification information for managing the device, and generates mapping information in which the device identification information for identifying the individual device is associated with the management identification information;
A device validity management unit that generates validity management information in which validity representing device validity or invalidity is associated with the device identification information, and
The device validity management unit generates the validity management information with the invalidity for the first device, and the validity with the validity for the second device treated as the same device as the first device. In response to generating management information, the mapping management unit associates the mapping information in which the device identification information of the second device is associated with the management identification information associated with the device identification information of the first device. Device management device to generate. In response to a replacement request for replacing the first device with the second device, the device validity management unit generates the validity management information with the invalidity for the first device, and the second device The device management apparatus according to claim 1, wherein the validity management information in which the validity is valid is generated. The mapping management unit includes first time information indicating a time at which the device identification information is associated with the management identification information, and indicates a time at which the association of the device identification information with the management identification information is released. The mapping information that does not include two-time information is generated as valid mapping information, and the mapping information that includes the first time information and the second time information is generated as invalid mapping information. Equipment management equipment. Setting information related to device settings is stored in association with the device identification information, and associated with the first device identification information in response to receiving the setting information acquisition request specifying the first device identification information from the device. A setting management unit for transmitting the setting information to the device;
When the setting management unit does not hold the setting information associated with the first device identification information, the association with the management identification information associated with the first device identification information is canceled with respect to the mapping management unit Requested to obtain the second device identification information,
The mapping manager acquires the second device identification information by searching for invalid mapping information,
The setting management unit associates the setting information associated with the second device identification information acquired by the mapping management unit with the first device identification information and the setting information associated with the first device identification information. The device management apparatus according to claim 3, wherein the device management device transmits the request to the requesting device. The setting management unit further holds, for each group of users, usage restriction information indicating the content of usage restrictions set for a device and an application that uses the device, and obtains the usage restriction information specifying a group The device management apparatus according to claim 4, wherein the use restriction information of the designated group is responded to the request source in response to the request. The device management apparatus according to claim 5, wherein the setting management unit updates the usage restriction information of the designated group according to the setting content in response to a usage restriction setting request designating the group. A user management unit for holding user information in which user identification information for identifying a user is associated with one or more pieces of management identification information;
A service management unit that issues service identification information for identifying a service to be provided to a user in response to a service purchase by the user, and generates service management information in which the user identification information is associated with the service identification information;
The device management apparatus according to any one of claims 1 to 6, further comprising: a usage history management unit that retains log information relating to the usage amount collected from the device as history information in association with the service identification information. The usage history management unit requests the service management unit to obtain the service identification information associated with the device identification information added to the log information,
The service management unit requests the user management unit to obtain the user identification information associated with the device identification information;
The user management unit requests the mapping management unit to obtain the management identification information associated with the device identification information;
The mapping management unit acquires the management identification information associated with the device identification information based on the mapping information and responds to the user management unit,
The user management unit acquires the user identification information associated with the management identification information acquired by the mapping management unit based on the user information and responds to the service management unit,
The service management unit responds to the usage history management unit with the service identification information associated with the user identification information acquired by the user management unit based on the service management information,
The device management apparatus according to claim 7, wherein the usage history management unit retains the log information as the history information in association with the service identification information acquired by the service management unit. The usage history management unit further holds, for each group of users, counter information indicating the usage frequency of a device and an application that uses the device, and is specified in response to an acquisition request for the counter information specifying a group. The device management apparatus according to claim 7, wherein the counter information of the group is responded to a request source.   10. The device management apparatus according to claim 1, further comprising a state management unit that collects state information representing a state of the device from the device and stores the state information in association with the device identification information. The device management apparatus according to any one of claims 1 to 10, further comprising a request reception unit that receives various requests to the device management apparatus. The device management apparatus according to claim 11, wherein the request reception unit has a Web API, and receives various requests to the device management apparatus via the network using the Web API. The device management apparatus according to any one of claims 1 to 12,
A device management system including one or more devices connected to the device management apparatus via a network. A device management method executed by a device management apparatus,
Issuing management identification information for managing the device and generating mapping information in which the device identification information for identifying the individual device is associated with the management identification information;
Generating validity management information in which validity representing the validity or invalidity of the device is associated with the device identification information, and
In response to generating the validity management information with the invalidity for the first device and generating the validity management information with the validity for the second device treated as the same device as the first device A device management method for generating the mapping information in which the device identification information of the second device is associated with the management identification information associated with the device identification information of the first device. On the computer,
A function of issuing management identification information for managing the device, and generating mapping information in which the device identification information for identifying the individual device is associated with the management identification information;
A function for generating validity management information in which validity indicating device validity or invalidity is associated with the device identification information; and
In response to generating the validity management information with the invalidity for the first device and generating the validity management information with the validity for the second device treated as the same device as the first device A program for generating the mapping information in which the device identification information of the second device is associated with the management identification information associated with the device identification information of the first device.

Images