System and method for controlling the system

Abstract

This enables the acquisition of events from devices in response to the display of a website's UI. [Solution] A system including a device management program executed when a website is accessed by a web browser and a device management service identifies the API resource to be used according to the display attribute indicating whether to show or hide each of the multiple UI elements provided by the device management program as UI components included in the website, notifies the device management service, and the device management service manages to obtain events from the device corresponding to the API resource to be used.

Description

Technical Field

[0001] The present invention relates to a system including a device management program executed when accessing a website with a web browser and a device management service, and a control method of the system.

Background Art

[0002] In a web application (hereinafter referred to as a web app) operating on a web browser, in recent years, due to the high performance of computers and the development of HTML, CSS, JavaScript, etc., it has become possible to implement more complex graphical user interfaces. Also, a technology for creating reusable UI components (such as web components) using web standard technologies has become common (hereinafter, UI components are referred to as UI parts). By using these technologies, for example, a device sales company can incorporate UI parts provided by a device manufacturer as an added value service of the device into the sales company's website, making it easier to realize the added value service provided by the manufacturer compared to the conventional method.

[0003] In recent years, image forming equipment such as Multi-Function Printers (MFPs) has become increasingly multifunctional, and it has become common for these equipment to connect to servers and cloud services via the internet to provide functions and services. Beyond image forming equipment, IoT (Internet of Things) systems are becoming widespread, where everything from houses and buildings to home appliances, automobiles, and electronic devices connect to servers via the internet as clients. For example, information obtained from sensors installed in devices is sent to a server, which then collects, analyzes, and utilizes that data to provide added value to service users. Thus, the proliferation of IoT systems has led to an increase in the number of devices connected to servers and the types and volume of data transmitted compared to the past. Machine learning-based prediction systems, in particular, require a large amount of input data to improve prediction accuracy, and consequently, the amount of data collected from devices increases. The increase in the number of devices and data volume has led to higher communication costs between devices and servers, as well as higher computational costs on the server side. Furthermore, the server also collects device information from devices for display in UI components. Specifically, this includes operational information such as whether or not device errors have occurred, consumable information indicating the remaining amount of consumables on the device, security settings and audit log information related to the device, and security information such as whether or not unauthorized tampering has occurred and the history of unauthorized logins. Patent Document 1 discloses a technology that controls the parameters received from a device in a prediction system according to the learning contribution rate, and suppresses unnecessary operating costs by instructing devices that send parameters with a low learning contribution rate to stop sending. [Prior art documents] [Patent Documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2021-26438 [Overview of the Initiative] [Problems that the invention aims to solve]

[0005] However, the technology described in Patent Document 1 makes it difficult to reduce the cost of collecting device information displayed using UI components that are not used in the prediction system. Furthermore, in cases where sales companies exist in various countries, they may not necessarily use all of the UI components provided by the manufacturer due to regional differences and the need for consistency with the sales companies' existing services. For example, some sales companies may be reluctant to send security information (such as device audit logs) to the server due to concerns about customer support. Therefore, it would be desirable for sales companies to be able to specify which UI components to use. It is also desirable to control the collection of device information from unused UI components from the device in order to protect customer data and reduce communication volume and operating costs.

[0006] The present invention aims to enable the acquisition of events from a device in response to the display of the UI. [Means for solving the problem]

[0007] To solve the above problems, the present invention provides a system including a device management program that is executed when a website is accessed by a web browser, and a device management service, the system comprising: notification means that identifies the API resource to be used according to the display attribute indicating whether to show or hide set for each of a plurality of UI elements provided by the device management program as UI components included in the website, and notifies the device management service; and management means in the device management service that manages the acquisition of events from the device corresponding to the API resource to be used. [Effects of the Invention]

[0008] According to the present invention, it is possible to acquire events from a device in response to the display of the UI. [Brief explanation of the drawing]

[0009] [Figure 1] This diagram shows the overall system configuration. [Figure 2] This is a diagram showing the system's hardware configuration. [Figure 3] This is a diagram showing the system's software configuration. [Figure 4] This figure shows an example of the device details screen. [Figure 5] This figure shows an example of a device details screen with some UI elements hidden. [Figure 6] This flowchart shows the process of displaying UI component 320 on customer-facing website 302. [Figure 7] This flowchart shows the notification process for API resources in Example 1. [Figure 8] This is a flowchart showing the process for issuing an event transmission instruction in Example 1. [Figure 9] This figure shows an example of a device status summary screen. [Figure 10] This figure shows an example of the device details screen. [Figure 11] This flowchart shows the notification process for API resources in Example 2. [Figure 12] This is a flowchart showing the process for issuing an event transmission instruction in Example 2. [Figure 13] This flowchart shows the process for sending transmission instructions for events that are always receivable. [Figure 14] This is a flowchart showing the process for issuing an event transmission instruction in Example 3. [Modes for carrying out the invention]

[0010] (Example 1) Figure 1 shows the overall system configuration. The system manages multiple devices via a network. As part of device management, the system provides information indicating the status of managed devices to a customer-facing website via the network, allowing customers to check the device status by browsing the website on their information terminals. The customer-facing website incorporates a device management program provided by the device management service. Therefore, the system in this embodiment includes a device management program that is executed when the website is accessed via a web browser, and a device management service. The system includes a device status management server 101, a customer information management server 103, managed devices 102, and information terminals 104. The system includes at least one of each of the devices 102 and information terminals 104.

[0011] The device status management server 101 provides a device management service for managing devices. The device status management server 101 collects various data about the managed device 102 from the device 102 and manages it as device status information. The device status information that the device status management server 101 collects from the device 102 includes, for example, error information, consumable information, and security information. Error information is information about abnormal statuses such as errors and alerts that occur in the device, such as paper jams and service call errors. Consumable information is information about consumables used in the device, such as toner levels. Security information is information about security, such as the device's security settings and unauthorized login history.

[0012] In addition, the device status management server 101 provides UI components for displaying the status of the device 102. The UI components are reusable UI components that utilize web standard technologies. The UI components provided by the device status management server 101 are incorporated as part of a page on the customer-oriented web site provided by the customer information management server 103 described later, and provide a function to display device status information on the customer-oriented web site. That is, the device status management server 101 provides a device management program executed when accessing the customer-oriented web site with the web browser of the information terminal 104 as a UI component. The device status management server 101 receives a UI component acquisition request for the customer-oriented web site and provides the UI component. The device status management server 101 provides an API (Application Programming Interface). Therefore, the system of this embodiment includes a device management program executed when accessing the customer-oriented web site with a web browser and the device status management server 101 that provides the device management service.

[0013] The device 102 is a network device held by a customer who is the management target of the system. The device 102 is managed by the device status management server 101 via the network 105 and is the management target of the device management service provided by the device status management server 101. The device 102 is, for example, an image forming apparatus having functions such as printing, FAX, copying, and scanning. The device 102 transmits the status of the device (itself) to the device status management server 101. In this embodiment, the case where the device 102 is an image forming apparatus such as a printer or an MFP (Multi Function Printer) will be described as an example, but it is not limited thereto. The device 102 may be any device capable of communication such as a 3D printer, an information processing apparatus such as a PC, an image processing apparatus such as a camera, or a smart home appliance, and capable of transmitting its own status information.

[0014] The customer information management server 103 manages customer information. The customer information managed by the customer information management server 103 is, for example, personal information such as customer names and contact information, information on devices held by customers, and the like. Further, the customer information management server 103 provides a customer-oriented website to customers. On the customer-oriented website, there are screens where customers can check the status of the devices they are using and sales information regarding the devices, and functions for making inquiries to the sales companies of the devices. The customer information management server 103, for example,

[0015] The information terminal 104 is an information processing device owned by a customer. The information terminal 104 is, for example, a personal computer (PC), a smartphone, a tablet, or the like. The information terminal 104 displays the customer-oriented website provided by the customer information management server 103 and accepts operations on the website. The information terminal 104 has a web browser, and by the customer specifying the URL (Uniform Resource Locator) of the customer-oriented website on the web browser, the customer-oriented website provided by the customer information management server 103 is displayed.

[0016] The device status management server 101, the device 102, the customer information management server 103, and the information terminal 104 are connected via the network 105. The network 105 is a communication network realized, for example, by a combination of a LAN (Local Area Network) and a WAN (Wide Area Network). Note that the network 105 only needs to be configured to be able to transmit and receive data, and the communication method is not limited. For example, the network 105 is composed of any one of a LAN, a WAN, a cellular network such as LTE or 5G, a wireless network, a telephone line, a dedicated digital line, or a combination thereof.

[0017] The device status management server 101 and the customer information management server 103 may each be internally composed of multiple servers. Furthermore, the device status management server 101 and the customer information management server 103 may each be implemented as virtual machines (cloud services) utilizing resources provided by a data center including an information processing device, or a combination thereof. Additionally, the device status management server 101 may include other servers (not shown) that provide functions other than those of the device status management server 101. Similarly, the customer information management server 103 may include other servers (not shown) that provide functions other than those of the customer information management server 103.

[0018] In this embodiment, the device status management server 101 is assumed to be a server operated by the device manufacturer that manufactured the device 102. The customer information management server 103 is assumed to be operated by the device sales company. Multiple customer information management servers 103 may be configured for each sales company. That is, the administrator (user) of the device status management server 101 and the administrator (user) of the customer information management server 103 are different. In this embodiment, it is assumed that customer information, including customer personal information, is to be independently managed by the customer information management server 103, and the device status management server 101 does not store customer information. Therefore, in this embodiment, a configuration will be described in which customer information is managed by the customer information management server 103, and information collected from the device 102 is managed by the device status management server 101.

[0019] Figure 2 shows the hardware configuration of the system. Figure 2(A) shows the hardware configuration of the device status management server 101, the customer information management server 103, and the information terminal 104. Here, the hardware configuration will be explained using the device status management server 101 as an example, but the customer information management server 103 and the information terminal 104 have the same hardware configuration as the device status management server 101.

[0020] The device state management server 101 includes a CPU 201, ROM 202, RAM 203, HDD 204, input device 205, output device 206, and communication interface 207. Each of these units is connected to the others via a system bus 200. The CPU (Central Processing Unit) 201 controls the entire device state management server 101. The CPU 201 reads control programs stored in the ROM 202 or HDD 204 and executes various control processes.

[0021] ROM 202 (Read Only Memory) 202 is a memory dedicated to data reading and stores, for example, basic control programs for information processing devices such as BIOS (Basic Input Output System). RAM (Random Access Memory) 203 is a memory that allows data reading and writing. RAM 203 is a direct storage device that functions, for example, as a work area for the CPU 201. HDD (Hard Disk Drive) 204 is an indirect storage device that stores various data and programs. In this embodiment, an example is described in which the device state management server 101 is equipped with HDD 204 as a storage device, but it is not limited to this, and other storage devices such as SSDs or disk drives for loading external media may also be equipped.

[0022] The input device 205 accepts user input. For example, a keyboard or pointing device may be connected to the input device 205. The output device 206 displays information to the user. For example, a display such as an LCD screen may be connected to the output device 206. The communication interface 207 is an interface for connecting to the network 105. The device status management server 101 communicates with external devices such as device 102, customer information management server 103, and information terminal 104 via the communication interface 207 and the network 105.

[0023] After the device state management server 101 starts up, the CPU 201 executes the BIOS and loads the OS from HDD 204 into RAM 203 in an executable state. The CPU 201 loads various software modules, described later, into RAM 203 from HDD 204 in an executable state as the OS operates. These software modules are executed and operated by the CPU 201 in cooperation with the above devices. The communication interface 207 is connected to the network 105 and is controlled by the CPU 201 in accordance with the OS operation to enable communication.

[0024] Figure 2(B) shows the hardware configuration of device 102. Device 102 includes a CPU 231, ROM 232, RAM 233, network controller 234, DKC 235, raster controller 237, print engine 238, operation panel 239, storage device 240, and device interface. Of these, the parts excluding the print engine 238 are sometimes referred to as the controller that manages the printer's control system. Each hardware component is connected to the system bus 230.

[0025] The CPU 231 controls the entire device 102 and comprehensively controls access to various devices connected to the system bus. The CPU 231 reads control programs stored in the ROM 232, or control programs and resource data (resource information) stored in the external memory 236 connected via the disk controller (DKC 235), and executes various control processes.

[0026] ROM232 stores programs to be executed by CPU231. RAM233 functions as the main memory, work area, etc., of CPU231. RAM233 is configured so that its memory capacity can be expanded by optional RAM connected to an expansion port (not shown). Storage device 240 is a storage means that functions as a large-capacity memory. Storage device 240 stores image data, various programs, and various setting information.

[0027] The network controller 234 is a communication controller, such as a network interface card (NIC). The CPU 231 exchanges data with external devices on the network 105 via the network controller 234. The DKC 235 controls access to storage devices such as the external memory 236. The external memory 236 stores program and resource data.

[0028] The control panel 239 displays a screen and accepts user instructions via the screen. In other words, the control panel 239 also functions as a display unit, such as an LCD panel, for setting the operating mode of device 102 and displaying the operating status of device 102. The control panel 239 is, for example, a touch panel. By associating input coordinates with display coordinates on the touch panel, a GUI can be configured that makes it appear as if the user can directly operate the screen displayed on the touch panel. The control panel 239 may also have buttons for performing operations such as specifying content data to print.

[0029] The raster controller 237 is a controller that converts print data described in, for example, the PDL language into image data. The print engine 238 uses known printing techniques to form an image on a recording medium (e.g., paper) based on the image data input from the raster controller 237. The printing method used by the print engine 238 can be, for example, electrophotography (laser beam method), inkjet method, or sublimation (thermal transfer method), and the method is not limited. The device I / F 241 is a connection interface for external devices that can be connected via USB, etc.

[0030] Figure 3 shows the software configuration of the system. First, the software configuration of the information terminal 104 will be explained. The software configuration of the information terminal 104 is realized by the CPU 201 of the information terminal 104 executing programs stored in the memory of the information terminal 104 (ROM 202, HDD 204, etc.). The information terminal 104 has a web browser 301, a customer-facing website 302, and UI components 320.

[0031] The web browser 301 is an application program installed on the information terminal 104 for viewing websites. For example, a typical web browser 301 is Microsoft Edge, developed by Microsoft.

[0032] The customer-facing website 302 is a customer-facing website provided by the customer information management server 103. When a customer specifies the URL of the customer-facing website on their web browser 301, the web browser 301 retrieves page information for displaying the customer-facing website from the UI management unit 350 of the customer information management server 103 and displays it. The customer-facing website consists of HTML, style sheets (CSS - Cascading Style Sheets), and programs that run on the web browser. One example of a program that runs on the web browser is JavaScript.

[0033] The customer-facing website 302 includes a UI display unit 310, a UI component display unit 311, an authentication information acquisition unit 312, a customer information acquisition unit 313, and UI components 320. The UI display unit 310 analyzes the page information of the customer-facing website obtained from the UI management unit 350 of the customer information management server 103 and displays the page information on the web browser 301. The UI display unit 310 also receives operations from customers on the pages of the customer-facing website and controls the UI component display unit 311, the authentication information acquisition unit 312, and the customer information acquisition unit 313.

[0034] The UI component display unit 311 inputs the parameters necessary for processing the UI component 320 to the UI component control unit 321. Specifically, these parameters include token information obtained from the customer information management server 103, customer information, and the display attributes of the UI elements of the UI component 320. The display attributes of the UI elements indicate whether the UI element is displayed or hidden. Details of the display attributes will be described later.

[0035] The authentication information acquisition unit 312 provides a function for customers to log in to the customer-facing website. The authentication information acquisition unit 312 acquires authentication information from the customer and transmits it to the customer authentication unit 351 of the customer information management server 103. The authentication information acquisition unit 312 then receives the result of user authentication performed by the customer authentication unit 351 and decides whether or not to allow the customer to use the functions of the customer-facing website 302 according to the authentication result. If authentication by the customer authentication unit 351 is successful, the authentication information acquisition unit 312 makes the functions of the customer-facing website 302 available to the customer. The authentication information is, for example, a combination of user ID and password entered by the customer. However, the authentication information is not limited to this and may also be information stored on an IC card or biometric information such as fingerprints or vein information.

[0036] Furthermore, the authentication information acquisition unit 312 requests and obtains token information necessary for using the UI component 320 from the customer authentication unit 351 of the customer information management server 103. The token information is a key information with an expiration date that has been issued in advance for the customer information management server 103, allowing the client to call the API provided by the device status management server 101. The token information is obtained, for example, by the customer authentication unit 351 of the customer information management server 103 specifying the client's authentication information and querying the authentication server (not shown). The token information is used by the UI component 320 to obtain device status information from the device status management server 101. The UI display unit 310 passes the token information obtained from the customer information management server 103 via the authentication information acquisition unit 312 to the UI component display unit 311, which then sets it in the UI component 320.

[0037] The customer information acquisition unit 313 acquires customer information held by the customer information management server 103. The customer information acquired by the customer information acquisition unit 313 from the customer information management server 103 mainly consists of device information held by the customer. The customer information acquisition unit 313 acquires customer information held by the customer information management server 103 via an API provided by the customer information management server 103. The UI display unit 310 passes the customer information acquired from the customer information management server 103 via the customer information acquisition unit 313 to the UI component display unit 311, which then sets it in the UI component 320.

[0038] UI component 320 is a program embedded in the customer-facing website. This program is a device management program that is executed when the website (customer website 302) is accessed using a web browser (web browser 301). UI component 320 is program information written in JavaScript and is configured as a program that does not depend on the libraries or frameworks used to build the website in which it is embedded. UI component 320, that is, the device management program embedded in the customer-facing website, is provided by the device status management server 101.

[0039] By pre-defining the UI components to be displayed on the customer website 302 in the page information of the customer website 302, the UI components are dynamically loaded when the customer website 302 page is displayed. Specifically, by writing the URL of the storage location of the UI component 320 in a script tag on the HTML of the customer website 302, the system will retrieve the UI component 320 from the device status management server 101 when the customer website 302 is displayed. In addition, the UI component to be embedded can be specified as a custom HTML tag, and the corresponding UI component can be displayed by writing that HTML tag on the HTML of the customer website 302. UI components such as the device details screen, device summary screen, and device list screen are available, and the HTML tags corresponding to these UI components can be specified. For example, in the case of the device details screen, the HTML tag is <device-details-page> ···< / device-details-page> It can be specified like this.

[0040] The UI elements displayed in UI component 320 consist of multiple elements. Here, as an example of UI component 320, the device details screen displayed on the customer website 302 will be described. Figure 4 shows an example of the device details screen. The device details screen 401 is a screen that displays the status information of one device specified by the customer. The device details screen 401 is a UI component 320 provided by the device status management server 101 and is displayed on the customer website 400. The customer website 400 is a page of the customer website displayed in the browser 301.

[0041] The device details screen 401 consists of device basic information 402 and device details tabs. Device basic information 402 displays the basic information of the device. This basic information includes, for example, the device name, the device's installation location, the product name, and the IP address. The device details tabs have multiple tabs that display device status information. In the example shown in Figure 4, the device details screen 401 has the operating status tab 403, the consumables status tab 404, and the security status tab 405 as UI elements. Figure 4 shows the state where the security status tab 405 is selected. The operating status tab 403 displays the device's error information from the device status information. The consumables status tab 404 displays the device's consumables information from the device status information. The security status tab 405 displays the device's security information from the device status information.

[0042] The security status tab 405 includes security configuration diagnostics 407, tampering detection 408, and login lockout detection 409 as UI elements. Additionally, the security status tab 405 displays a top message 406 indicating the status of the security status tab 405 as needed. In the example shown in Figure 4, the top message 406 indicates that there are errors requiring user action.

[0043] Security Settings Diagnostic 407 displays the diagnostic results to determine whether the device's security settings are configured to be secure. For example, in the example shown in Figure 4, if all settings have not been changed from their default values, it determines that the settings may not have been modified to suit the customer's usage environment and displays a warning. It may also be configured to display a warning if the recommended security settings are not set for important security settings.

[0044] Tampering detection 408 displays the verification results for whether the device's firmware or the software of the applications installed on the device have been tampered with. In the example shown in Figure 4, firmware tampering has been detected and is displayed as an error. Login lockout detection 409 displays the occurrence of a lockout and the username of the user who attempted to log in to the device if a lockout occurs during login. A lockout is a function that temporarily prohibits a user from logging in to the device if the number of failed login attempts within a certain period of time exceeds a predetermined number due to reasons such as mismatched ID and password. Login lockout detection 409 displays a message indicating the possibility of an unauthorized user attempting to log in if a lockout occurs.

[0045] In this embodiment, each element of the UI component 320 can be specified with a display attribute ("display") that controls the display and hiding of the UI element. The display attribute is information indicating whether to display or hide each of the multiple UI elements provided by the device management program as UI components included in the website. The display attribute is set by the provider that provides the customer-facing website incorporating the device management program, which is a UI component. For example, the display attribute is set by the device sales company that manages the customer information management server 103 that provides the customer-facing website. When the display attribute of a UI element is specified as "visible", the UI element is displayed. On the other hand, when the display attribute of a UI element is specified as "hidden", the UI element is hidden. The source code below shows an example of source code that specifies the display attribute of the security status tab 405 as "visible". var securityStatusTab = document.querySelector('security-status-tab') securityStatusTab.setAttribute('display', 'visible')

[0046] By setting the display attribute to "display," the device state management server 101 instructs device 102 to notify event information for obtaining information on API resources necessary for display through the processes shown in Figures 7 and 8 described later. In this embodiment, it is assumed that the display attribute of each UI element of the UI component 320 is set to "hidden" by default, and that the display attribute of the UI elements of the UI component 320 used as the implementation on the customer-facing website 302 side that incorporates the UI component is set to "display." Alternatively, the display attribute of each UI element may be set to "display" by default, and the display attribute of each UI element of the UI component 320 that you want to hide may be set to "hidden" depending on customer requests or the circumstances of the sales company.

[0047] Figure 5 shows an example of a device details screen with some UI elements hidden. The device details screen 412 shown in Figure 5 is a UI component 320 provided by the device status management server 101 and is displayed on the customer website 410. The device details screen 412 displays the operational status tab 403 and the consumables status tab 404, but the hidden tab 411 corresponding to the security status tab 405 is not displayed. In Figure 4, the operational status tab 403, consumables status tab 404, and security status tab 405 were displayed as device detail tabs, but in Figure 5, the security status tab 405 is hidden. Therefore, if the display attributes of the operational status tab 403, consumables status tab 404, and security status tab 405 are all set to "display", the device details screen 401 in Figure 4 is displayed. On the other hand, if the display attributes of the operational status tab 403 and consumables status tab 404 are set to "display", and the display attribute of the security status tab 405 is set to "hidden", the device details screen 412 in Figure 5 is displayed. In this way, the UI component 320 controls the content (UI elements) to be displayed according to the display attributes specified for each element of the UI component 320.

[0048] Returning to the explanation of Figure 3, the UI component 320 includes a UI component control unit 321, a customer information management unit 322, a device information acquisition unit 323, an API resource management unit 324, and an API resource notification unit 325. The UI component control unit 321 controls the display of the UI of the UI component 320 according to the display attributes set for the UI elements. Specifically, the UI component control unit 321 displays UI elements included in the UI component 320 whose display attribute is set to "display". On the other hand, the UI component control unit 321 does not display UI elements included in the UI component 320 whose display attribute is set to "hidden". The UI component control unit 321 also acquires information necessary for UI display from the customer information management unit 322 and the device information acquisition unit 323. Specifically, the UI component control unit 321 stores customer information acquired by the customer information acquisition unit 313 from the customer information management server 103 in the customer information management unit 322, and acquires the customer information necessary for UI display from the customer information management unit 322 when displaying the UI. The UI component control unit 321 acquires device status information necessary for UI display from the device status management server 101 via the device information acquisition unit 323 when displaying the UI. The UI component control unit 321 also accepts customer operations on the UI component 320 and controls the response thereto. Furthermore, the UI component control unit 321 refers to the display attributes of the UI elements contained in the UI component 320 to determine whether to display or hide the UI component, and also acquires API resources corresponding to the UI component via the API resource management unit 324. API resources are resources on which the functions of the API are executed, and in this embodiment, the API resources are data necessary for displaying the UI component (mainly data representing the device status).

[0049] The customer information management unit 322 holds customer information received from the customer-facing website 302. This customer information includes device information and other data held by the customer, which is obtained by the customer information acquisition unit 313 of the customer-facing website 302 from the customer information management server 103. The UI component control unit 321 receives the customer information obtained by the customer information acquisition unit 313 from the customer information management server 103 as parameters and stores it in the customer information management unit 322. Then, when displaying the UI, the UI component control unit 321 retrieves the necessary customer information from the customer information management unit 322 and displays it.

[0050] The device information acquisition unit 323 acquires device status information from the device status management server 101. This device status information includes, for example, error information occurring on the device, such as paper jams and service call errors; consumable information such as the device's toner level; and security information such as the device's security settings and unauthorized login history. The UI component control unit 321 acquires the device status information from the device status management server 101 via the device information acquisition unit 323 and displays it on the device details screen (Figures 4 and 5). For example, in Figure 4, the UI component control unit 321 displays error information on the operating status tab 403, consumable information on the consumable status tab 404, and security information on the security status tab 405. Customers can check the display of device status information on the device details screen and take action regarding errors and warnings on the device.

[0051] The API resource management unit 324 holds information about the UI elements of the UI component 320 and their corresponding API resources. Specifically, the API resource management unit 324 associates the UI elements of the UI component 320 with the API resources required to display those UI elements and holds this information as mapping information. A specific example of the data held by the API resource management unit 324 is shown in Table 1. Table 1 is an example of a table that holds mapping information between the UI elements of the UI component 320 and API resources. [Table 1]

[0052] Table 1, the UI element and API resource mapping information table, includes the UI element name, API resource name, and parent UI element name of the UI component. The UI element name column of the UI component shows the UI element name that identifies the UI element contained in UI component 320. The API resource name column shows the API resource name corresponding to the UI element in the UI element name column. The parent UI element name column shows the name of the parent UI element of that UI element. Note that if the value of the API resource name column is "-", it indicates that there is no corresponding API resource. If the value of the API resource name column is "-", a UI element for which there is no corresponding API resource corresponds to a parent UI element that has child UI elements.

[0053] For example, in Table 1, the parent UI element "device-details-page" contains four child UI elements. The four child UI elements are "device-basic-info", "operation-status-tab", "consumable-status-tab", and "security-status-tab". "device-details-page" corresponds to the device details screen (Figures 4 and 5). Using Figure 4 as an example, "device-basic-info" corresponds to the device details screen 401 of "device-details-page", and "device-basic-info" corresponds to the device basic information 402. "operation-status-tab" corresponds to the operation status tab 403, "consumable-status-tab" corresponds to the consumable status tab 404, and "security-status-tab" corresponds to the security status tab 405. In other words, the device details screen 401 includes the following UI elements: device basic information 402, operating status tab 403, consumables status tab 404, and security status tab 405.

[0054] The “security-status-tab” corresponding to Security Status tab 405 further contains the following three child UI elements: “security-settings-diagnosis-alert-text”, “security-verification-alert-table”, and “security-login-lockout-alert-table”. “security-settings-diagnosis-alert-text” corresponds to Security Settings Diagnosis 407, “security-verification-alert-table” corresponds to Tampering Detection 408, and “security-login-lockout-alert-table” corresponds to Login Lockout Detection 409. In other words, Security Status tab 405 includes Security Settings Diagnosis 407, Tampering Detection 408, and Login Lockout Detection 409 as UI elements.

[0055] Table 1 shows that the UI element “security-settings-diagnosis-alert-text” is associated with the API resource “security-alert(settings-diagnosis)”. This indicates that the information displayed by the UI element “security-settings-diagnosis-alert-text” requires the API resource “security-alert(settings-diagnosis)”. In this way, the UI element and API resource mapping information table associates the API resources required to obtain the information displayed by each UI element. The API resource notification unit 325 notifies the device state management server 101 of the usage status of the API resources of the UI element 320, in accordance with instructions from the UI component control unit 321. Thus, the UI component control unit 321, API resource management unit 324, and API resource notification unit 325 of the UI element 320 function as notification means for notifying the device state management server 101 of API resources.

[0056] Next, the software configuration of the device state management server 101 will be described. The software configuration of the device state management server 101 is realized by the CPU 201 of the device state management server 101 executing programs stored in the memory of the device state management server 101 (ROM 202, HDD 204, etc.). The device state management server 101 includes a UI component management unit 330, an API receiving unit 331, a device state management unit 332, an event management unit 333, and an event receiving unit 334.

[0057] The UI component management unit 330 manages the UI components 320 and receives requests for UI component acquisition from the customer-facing website 302 of the Web browser 301 running on the information terminal 104, and provides the UI components 320. The UI components 320 are program information written in JavaScript and are configured as programs that do not depend on the libraries or frameworks used to build the website to which they are embedded. For example, the UI components 320 are programs implemented using Web Components, a technology that creates reusable UI components using Web standard technologies. Alternatively, the UI components 320 may be configured as programs that can be embedded in accordance with the library framework used to build the customer-facing website of the customer information management server 103.

[0058] The API receiving unit 331 receives API requests from the device state management server 101 via the UI component 320 operating on the information terminal 104. Specifically, it receives API resource notifications sent from the API resource notification unit 325 of the UI component 320 operating on the information terminal 104, and device information acquisition requests sent from the device information acquisition unit 323. The API receiving unit 331 then executes processing according to the called API. For example, if it receives an API resource notification, the API receiving unit 331 instructs the event management unit 333 to send an event notification to device 102. If it receives a device information acquisition request, the API receiving unit 331 obtains device state information from the device state management unit 332 and returns it to the information terminal 104 as a response.

[0059] The event management unit 333 manages the acquisition of events from device 102 by instructing device 102 to start or stop event notifications. The instruction information that the event management unit 333 sends to device 102 includes the event name, which is information to uniquely identify the event to be notified, and a specification to start or stop sending the event. The correspondence between API resources and device events is shown in Table 2. Table 2 is an example of a table that holds mapping information between API resources and device events. The table showing the correspondence between API resources and device events shown in Table 2 is maintained by the event management unit 333. [Table 2]

[0060] In the mapping table between API resources and device events, API resource names and device event names are managed in association. The API resource name column is the API resource name that identifies the API resource. The device event name column is the event name of the device corresponding to the API resource. To obtain information about the API resource in the API resource name column, the event notification in the corresponding device event name column is required. For example, when using the "operation-alerts" API resource, notification of the device event "alert-occurred" is required. Suppose the event management unit 333 instructs device 102 to start notifying "alert-occurred" indicating the occurrence of an error. After receiving the instruction to start error notification, device 102 then notifies the event receiving unit 334 of the device status management server 101 of the occurrence of an event that is subject to error, such as a paper jam, along with alert level information such as error or warning. Note that the instruction information for event notification may also include the timing of the event notification (e.g., upon occurrence (immediately) / periodically / at startup). Furthermore, while this embodiment shows an example where the event name is explicitly specified along with the send / stop instruction, it is also possible to configure the system to specify only the event name to be sent.

[0061] The event receiving unit 334 receives various event notifications from device 102. Event notifications from device 102 include, for example, events that notify error information when errors occur, such as paper jams or service calls. Other event notifications include events that periodically notify the device's toner level and events that notify changes in the device's security settings. The information from the event notifications received from device 102 is stored as device status information by the device status management unit 332. The device status management unit 332 manages device status information such as the operating status, consumable status, and security status of device 102.

[0062] Next, the software configuration of the customer information management server 103 will be described. The software configuration of the customer information management server 103 is realized by the CPU 201 of the customer information management server 103 executing programs stored in the memory of the customer information management server 103 (ROM 202, HDD 204, etc.). The customer information management server 103 has a UI management unit 350, a customer authentication unit 351, and a customer information management unit 351.

[0063] The UI management unit 350 holds UI information (page information) for the customer-facing website. Specifically, it holds program information written in HTML, CSS, and Javascript as page information. In response to a request from the web browser 301 of the information terminal 104 to retrieve page information for displaying the customer-facing website, the UI management unit 350 returns the page information.

[0064] The customer authentication unit 351 provides login functionality for users of the customer-facing website 302. The customer authentication unit 351 issues an ID and password for user authentication to users who register to use the customer-facing website 302 and stores them as customer authentication information. The customer authentication unit 351 also receives authentication requests from the customer-facing website 302 and performs user authentication by comparing the ID and password values ​​received as parameters with the authentication information held by the customer authentication unit 351. If there is user information in which the received parameters and the authentication information held by the customer authentication unit 351 match, the customer authentication unit 351 approves authentication and allows the user to use the service. The customer authentication unit 351 then sends the authentication result back to the customer-facing website 302 that made the authentication request.

[0065] The Customer Information Management Department 352 manages customer information. Customer information includes device information owned by the customer, and maintains a list of devices registered by the customer. It receives customer information retrieval requests from the customer-facing website 302 and returns the customer information held by the Customer Information Management Department 352.

[0066] Next, the software configuration of device 102 will be described. The software configuration of device 102 is realized by the CPU 231 of device 102 executing programs stored in the memory of device 102 (ROM 232, external memory 236, storage device 240, etc.). Device 102 has an event instruction receiving unit 340, a data acquisition unit 341, and an event notification unit 342.

[0067] The event instruction receiving unit 340 receives event notification instructions from the device status management server 101. Based on the received event notification instructions, the event instruction receiving unit 340 notifies the data collection unit 341 of the event notification targets. The data collection unit 341 collects various data based on the event notification targets notified by the event instruction receiving unit 340 and transmits them to the event notification unit 342. The data collection unit 341 also stores the event notification targets notified by the event instruction receiving unit 341.

[0068] The event notification unit 342 notifies the device status management server 102 of the data collected by the data collection unit 341. For example, if the event instruction receiving unit 340 receives an "alert-occurred" message indicating an error, the data collection unit 341 detects the error in device 102 and generates event data for the error notification. The event notification unit 342 then notifies the device status monitoring server 101 of the event data for the error notification generated by the data collection unit 341.

[0069] In this embodiment, the system accepts display / hide settings for UI elements, and the content (UI elements) displayed on the customer-facing website is determined according to these settings. Figure 4 shows the device details screen 401 when the security status tab 405 is displayed, and Figure 5 shows the device details screen 412 when the security status tab 405 is not displayed (hidden tab 411). Figure 4 shows the device details screen 401 where the display attribute of the security status tab 405 is set to "display," and Figure 5 shows the device details screen 412 where the display attribute of the security status tab 405 is set to "hidden." When the display attribute of the security status tab 405 is set to "hidden," the security status 405 and its child UI elements are not displayed. Furthermore, when the display attribute of the security status tab 405 is set to "hidden," API resources related to the security status 405 and its child elements, as well as device events corresponding to those API resources, are not notified from device 102 to the device status management server 101. Specifically, API resources corresponding to UI elements that have "security-status-tab" as their parent UI element in Table 1 are API resources that are not used. The API resources “security-alert(settings-diagnosis)”, “security-alert(verification)”, and “security-alert(login-lockout)” are not used. Unused API resources are not notified to the device state management server 101 from the API resource notification unit 325 of the UI component 320 of the information terminal 104. Therefore, the device state management server 101 does not issue notification instructions to the device 102 for events corresponding to these API resources, and the device state management server 101 does not receive corresponding events from the device 102. As a result, in Table 2, the events of the device 102 corresponding to the above unused API resources are events that the device state management server 101 does not receive notifications for from the device 102.The following events will not trigger notifications from the device: “security-settings-snapshotted”, “security-settings-changed”, “user-login”, “user-logout”, and “verification-completed”.

[0070] By changing the display attribute of the security status tab 405 from "hidden" to "displayed," the aforementioned API resource is notified to the device status management server 101, and the device status management server 101 sends a notification instruction for the corresponding event to device 102. This initiates event reception from device 102, making it possible to obtain the API resource information necessary for displaying the security status 405.

[0071] Figure 6 is a flowchart illustrating the process of displaying UI components 320 on the customer-facing website 302. Each process in this process for the information terminal 104 is implemented by the CPU 201 of the information terminal 104 executing a program stored in the memory (ROM 202, HDD 204, etc.) of the information terminal 104. Each process in this process for the device state management server 101 is implemented by the CPU 201 of the device state management server 101 executing a program stored in the memory (ROM 202, HDD 204, etc.) of the device state management server 101. Each process in this process for the customer information management server 103 is implemented by the CPU 201 of the customer information management server 103 executing a program stored in the memory (ROM 202, HDD 204, etc.) of the customer information management server 103. Each process in this process for the device 102 is implemented by the CPU 231 of the device 102 executing a program stored in the memory (ROM 232, external memory 236, storage device 240, etc.) of the device 102.

[0072] This process is initiated when customer 106 performs an operation on information terminal 104 to display customer-facing website 302. In S501, information terminal 104 receives the operation from customer 106 to display customer-facing website 302. Specifically, information terminal 104 receives a display operation specifying the URL of customer-facing website 302 on its web browser 301.

[0073] In step S502, the web browser 301 of the information terminal 104 requests the customer information management server 103 to retrieve a page of the customer-facing website 302. Upon receiving the request to retrieve the page of the customer-facing website 302, the customer information management server 103 returns a login page for the customer to log in to the customer-facing website 302 to the web browser 301 of the information terminal 104.

[0074] In S503, the web browser 301 displays the login page for the customer website 302, which was obtained from the customer information management server 103. The login page displays an area for accepting the input of authentication information for login. In S504, the customer website 302 accepts the input of authentication information from the customer 106. The authentication information is, for example, a combination of user ID and password.

[0075] In S505, the customer-facing website 302 performs authentication processing for login using the authentication information entered by customer 106. Specifically, the UI display unit 310 receives the authentication information entered by customer 106 and sends the authentication information to the customer information management server 103 via the authentication information acquisition unit 312. The customer authentication unit 351 of the customer information management server 103, upon receiving the authentication information, performs authentication processing and returns the authentication result to the customer-facing website 302. If the authentication process is successful, login to the customer-facing website 302 is performed, and the process in S506 is executed. On the other hand, if the authentication process is unsuccessful, login to the customer-facing website 302 is not possible, and this process terminates.

[0076] In S506, the customer-facing website 302 obtains customer-facing page information. Specifically, the UI display unit 310 of the customer-facing website 302 requests customer-facing page information from the customer information management server 103. The UI management unit 350 of the customer information management server 103, having received the request for customer-facing page information, returns the customer-facing page information to the UI display unit 310. In S507, the UI display unit 310 of the customer-facing website 302 displays the customer-facing page information received from the customer information management server 103. The customer-facing page is, for example, the customer-facing website 400, and in the initial display, it is displayed with the home screen (not shown) open. In this embodiment, the UI components to be displayed on the customer website 302 are defined in advance in the page information of the customer website 302.

[0077] In S508, the customer-facing website 302 accepts a screen transition operation from the customer 106. In this embodiment, it is assumed that the customer-facing website accepts a screen transition operation from the home screen to the device details screen. When the customer 106 selects a device to be checked from the devices on the device list screen (not shown) displayed by selecting a menu on the home screen, the customer-facing website 302 displays a device details screen where the details of the selected device can be checked. An example of the device details screen is shown in Figures 4 and 5. The device details screen is configured as a UI component 320 provided by the device status management server 101, and the device details screen is displayed by executing the processes S509 to S518 described below.

[0078] In S509, the customer-facing website 302 obtains the UI components 320 for the device details screen in order to display the device details screen. Specifically, the UI component display unit 311 of the customer-facing website 302 requests UI component information from the device status management server 101, and the UI component management unit 330 of the device status management server 101, upon receiving the request, returns the UI component information to the customer-facing website 302.

[0079] In S510, the customer-facing website 302 obtains display settings and customer information from the customer information management server 103, which are to be specified as parameters for the UI component 320. The customer information obtained here is device information associated with the customer logged into the customer-facing website 302. The UI component display unit 311 of the customer-facing website 302 sends a request to the customer information management server 103 via the customer information acquisition unit 313, specifying a customer ID that uniquely identifies the customer. The customer information management unit 352 of the customer information management server 103, upon receiving the request, returns customer information (device information used by the customer) that matches the customer ID to the customer-facing website 302. The customer information includes a device name and an ID that uniquely identifies the device used by the customer. The device name included in the customer information is the same as the device name in the device basic information 402 in Figure 4. The customer-facing website 302 also obtains the display settings for the UI component corresponding to customer 106 from the customer information management server 103. The display settings include information about the display attributes (information indicating whether to show or hide) set for each UI element. Alternatively, the display attribute information (display settings) may be included in the source code of each UI element included in the customer-facing web page beforehand, and S510 may retrieve only customer information from the customer information management server 103.

[0080] In S511, the customer-facing website 302 obtains token information to be specified as a parameter for the UI component 320. The token information obtained here is specified by the UI component 320 as authentication information for the API call to the device state management server 101. The UI component display unit 311 of the customer-facing website 302 sends a request to the customer information management server 103 to obtain token information via the authentication information acquisition unit 312. The customer authentication unit 351 of the customer information management server 103, upon receiving the request, returns the obtained token information to the customer-facing website 302. Here, the token information is obtained by specifying the client authentication information that has been issued in advance for the customer information management server 103 and the customer ID that identifies the customer, and submitting an issuance request to the authentication server (not shown). The client authentication information is, for example, a combination of user ID and secret.

[0081] In S512, the customer-facing website 302 sets the customer information obtained in S510, the token information obtained in S511, and the "Display" display attribute for the UI components to be displayed from among the UI components obtained in S509. Based on the display settings obtained in S510, the customer-facing website 302 identifies the UI components to be displayed and sets the customer information, token information, and the "Display" display attribute as parameters for the UI components to be displayed. These values ​​are set as parameters for the UI component 320 by the UI component display unit 311 of the customer-facing website 302 and are received by the UI component control unit 321 of the UI component 320.

[0082] In S513, the UI component control unit 321 identifies the API resources to be used based on the display attributes of the UI component 320 specified in S512. Specifically, the API resource management unit 324, as instructed by the UI component control unit 321, identifies the API resources corresponding to the display attributes of the UI elements of the UI component 320 and its child UI elements whose display attributes are set to "display".

[0083] In S514, the UI component control unit 321 notifies the device state management server 101 of the API resource identified in S512. Specifically, the API resource notification unit 325, which receives the API resource identified in S512 from the UI component control unit 321, calls the API of the device state management server 101 and notifies the device state management server 101 of the API resource to be used. Details of the processing in S513 and S514 will be described later with reference to Figure 7.

[0084] In S515, the device state management server 101 identifies the device event corresponding to the API resource to be used. Specifically, the API receiving unit 331 of the device state management server 101 receives a notification of the API resource to be used from the API resource notification unit 325 and identifies the device event corresponding to the API resource to be used.

[0085] In S516, the device status management server 101 sends a command to the device instruction receiving unit 340 of device 102 to start sending the event identified in S515. This initiates notification of the event identified in S515 by device 102 to the device status management server 101. Details of the processing in S515 and S516 will be described later with reference to Figure 8.

[0086] In S517, device 102 collects data based on the event notification received by device instruction receiving unit 340 and notifies device status management server 101. Specifically, event instruction receiving unit 340 notifies data collection unit 341 of the event notification target based on the event transmission start instruction identified in S515 received from device status management server 101. Data collection unit 341 collects various data within device 102 based on the event notification target notified by event instruction receiving unit 340. Event notification unit 342 transmits the data collected by data collection unit 341 to event receiving unit 334 of device status management server 101.

[0087] In S518, the UI component 320 obtains device status information (device error information, consumable remaining amount information, security information) from the device status management server 101. The devices to be obtained here are the devices to be displayed on the device details screen and are the devices selected by customer 106 in S508. The UI component control unit 321 obtains the device status information from the device status management server 101 via the device information acquisition unit 323. The request from the device information acquisition unit 323 to the device status management server 101 for obtaining device status information is sent as a request to the API of the device status management server 101. At this time, the token information specified by the customer website 302 and the device ID that uniquely identifies the device are specified as parameters of the API. The device status management unit 331 of the device status management server 101 receives the request from the device information acquisition unit 323 for obtaining device status information and returns device status information that matches the device ID specified as a parameter.

[0088] In S519, the UI component 320 displays the device details screen 401. Specifically, the UI component control unit 321 generates and displays the device details screen 401 page based on the customer information received as parameters from the customer website 302 in S512 and the device status information acquired in S518.

[0089] The above process will be explained using the example of a customer-facing website UI component (UI element) that displays device status information, where the display attributes for error information and consumable level information are set to "display," and the display attribute for security information is set to "hidden." In S514, the API resources used to display error information and consumable level information are notified to the device status management server 101. On the other hand, the API resources used to display security information are not notified to the device status management server 101. Upon receiving the notification, the device status management server 101 identifies the event corresponding to the API resource to be used in S515, and in S516 instructs device 102 to start sending the identified event. This makes it possible to manage the notification of events from device 102, and to manage the system so that only data to be displayed on the customer-facing website is obtained from device 102, and data that is not to be displayed is not obtained from device 102.

[0090] Here, the notification process for the API resources used in S513 and S514 will be explained using Figure 7. Figure 7 is a flowchart showing the API resource notification process in Embodiment 1. In this embodiment, the UI component 320 identifies the API resources to be used according to the display attributes of the UI elements and notifies the device state management server 101. Each process shown in Figure 7 is realized when the CPU 201 of the information terminal 104, which has a web browser 301 displaying the customer website 302, executes a program for displaying the customer website.

[0091] In S601, the UI component control unit 321 of the UI component 320 acquires information about the UI elements contained in the UI component 320. The UI element information acquired here refers to all the UI elements of the UI component 320 included in the screen to be displayed, and each UI element includes display attributes. All UI elements refer to all the UI elements included in Table 1, for example, in the case of the device details screen 401.

[0092] In S602, the UI component control unit 321 obtains the API resource corresponding to one of the UI elements acquired in S601. Specifically, it queries the API resource management unit 324, which identifies the API resource corresponding to the UI element. The API resource management unit 324 identifies the API resource corresponding to the UI element using a table (Table 1) that defines the mapping between the UI elements and API resources it holds.

[0093] In S603, the UI component control unit 321 determines whether it was able to obtain an API resource from the API resource management unit 324 in S602. If it was able to obtain an API resource from the API resource management unit 324, that is, if there is an API resource corresponding to the UI element, the UI component control unit 321 performs the process in S604. On the other hand, if it was not able to obtain an API resource from the API resource management unit 324, that is, if there is no API resource corresponding to the UI element, the UI component control unit 321 performs the process in S606. Cases where an API resource corresponding to a UI element cannot be obtained include, for example, the parent UI element that has a UI element as a child, such as "device-details-page" and "security-status-tab" in Table 1.

[0094] In S604, the UI component control unit 321 refers to the display attribute of the UI element and determines whether the display attribute is "displayed". If the display attribute of the UI element is "displayed", the UI component control unit 321 performs the process in S605. On the other hand, if the display attribute of the UI element is "hidden", the UI component control unit 321 performs the process in S606. If the display attribute is not specified, the process may follow the display attribute of the parent UI element, or a display / hidden setting for when it is not specified may be set in advance and the system may follow that setting.

[0095] In S605, the UI component control unit 321 identifies API resources with the display attribute "display" as API resources to be used and adds them to the list. Specifically, the UI component control unit 321 adds them to the internal list as resources to be notified to the device state management server 101 in S607, as described below. In S606, the UI component control unit 321 determines whether all UI elements obtained in S601 have been processed. If there are any unprocessed UI elements, it returns to S602 and executes the processes described in S602 to S605 on the unprocessed UI elements. On the other hand, if all have been processed and there are no unprocessed UI elements, it performs the process in S607.

[0096] In S607, the UI component control unit 321 notifies the device state management server 101 of the API resources to be used and the identified API resources. Specifically, it passes a list of identified API resources to the API resource notification unit 325, which then calls the API of the device state management server 101 and notifies the device state management server 101 of the API resources to be used. The information notified to the device state management server 101 is, for example, a list of information that bundles together the API resource name (API resource name in Table 1) used to identify the API resource and a value indicating whether or not that resource is being used for each API resource that corresponds to a UI element on the page.

[0097] Through the above process, the UI component control unit 321 obtains the API resource corresponding to the UI element and identifies the API resource to be used if the display attribute set for the UI element is set to display the UI element. Then, it notifies the device state management server 101 of the API resource to be used. This makes it possible to identify the API resource to be used and notify the device state management server 101 according to the display attribute indicating whether to show or hide each of the multiple UI elements included in the website.

[0098] Next, the processing flow of event transmission instructions from the device state management server 101 to the device 102 in S515 and S516 will be explained using Figure 8. Figure 8 is a flowchart showing the process of issuing event transmission instructions in Example 1. Each process shown in Figure 8 is realized by the CPU 201 of the device state management server 101 executing a program stored in the memory (ROM 202, HDD 204, etc.) of the device state management server 101.

[0099] This process is initiated by the device state management server 101 upon receiving notification of the API resource to be used (S607) from the API resource notification unit 325 of the UI component 320. In S611, the API receiving unit 331 of the device state management server 101 obtains the API resource information received as a request from the notification of the API resource to be used. The request includes the API resource name and a value indicating the use of that resource. The API receiving unit 331 then notifies the event management unit 333 of the API resource included in the request.

[0100] The event management unit 333 performs the S612 and S613 processes for one of the notified API resources. In S612, the event management unit 333 retrieves the device event corresponding to one of the notified API resources. Specifically, the event management unit 333 identifies the event corresponding to the API resource using a table (Table 2) which defines the mapping between API resources and their corresponding device events.

[0101] In S613, the event management unit 333 generates event instruction information that instructs the device 102 to begin sending an event, as described in S615. The event instruction information that instructs the device to begin sending an event includes the event name and the transmission instruction. In S614, the event management unit 333 determines whether all notified API resources have been processed. If processing of all notified API resources is complete, it proceeds to S615. On the other hand, if there are any unprocessed API resources, it returns to S612 and executes the processing from S612 for the unprocessed API resources.

[0102] In S615, the event management unit 333 sends the event instruction information generated in S613 to device 102. As a result, the event sent in the event instruction information is notified from device 102 to the device state management server 101. Through the above process, it becomes possible to manage the acquisition of events from device 102 by instructing device 102 to start sending events corresponding to the API resources to be used, as notified from the UI component 320, to the device state management server 101.

[0103] As described above, according to this embodiment, when the display attribute of the UI component 320 provided by the device state management server 101 is specified as "displayed," the API resources necessary for displaying that UI are identified, and the device 102 is instructed to send event notifications corresponding to those API resources. This allows control to collect only the information necessary for the UI to be displayed from the device 102. Therefore, in a system that provides UI components (device management programs), it is possible to specify the UI to be displayed on the embedded side of the UI component, and by instructing the device to send only the information necessary for that display, it is possible to manage the transmission of unnecessary information to the server side. By controlling the data collected from the device 102 according to the display of the UI, the collection of data that is not to be displayed can be suppressed, reducing communication volume and operating costs, and further enhancing customer data protection.

[0104] (Example 2) Example 1 shows an example where the display attribute of UI component 320 is set to "displayed," instructing device 102 to start event notifications corresponding to that UI element. This assumes the process when UI component 320 is first used on the customer-facing website 302, but there may be cases where UI component 320 is no longer used due to modifications to the customer-facing website 302, etc. Also, Example 1 does not consider the case where API resources corresponding to UI elements of UI component 320 overlap, but this is possible. Example 2 takes these into consideration, and when the display attribute of UI component 320 is set to "hidden," event notifications from the now unnecessary device 102 are stopped. Furthermore, Example 2 describes a configuration that implements control considering the case where API resources corresponding to UI elements overlap. Note that in this example, only the differences from Example 1 will be described, and similar configurations and processes will be denoted by the same reference numerals and their explanations will be omitted.

[0105] This section describes the case where API resources overlap. Figures 9 and 10 show examples of UI elements for UI components 320 displayed on the customer-facing website 302. Figure 9 shows an example of the device status summary screen. Figure 10 shows an example of the device details screen. In this embodiment, we will explain the case where the API resources corresponding to the UI elements of the device status summary and the API resources corresponding to the UI elements of the operating status tab 403 on the device details screen overlap.

[0106] First, let's explain the device status summary screen in Figure 9. The device status summary screen is a screen that summarizes the status of all devices associated with a customer who has logged into the customer website 700. The customer website 700 is a page of the customer website displayed in the browser 301. The customer website 700 displays the device status summary screen 701, which is a UI component 320 provided by the device status management server 101. The device status summary screen 701 includes the operational status summary 702, the consumables status summary 703, the security status summary 704, and the operational status message list 705.

[0107] The Operational Status Summary 702 is a summary screen of the operational status of devices used by the customer. The Operational Status Summary 702 displays the number of devices in a pie chart, categorized by the status indicating the device's operational status. The status indicating the device's operational status is classified into categories such as normal (no errors), warning, error, service call error, and unknown status. In the example shown in Figure 9, the customer uses 10 devices, with 8 in normal (no errors) status and 2 in error status.

[0108] The consumable status summary 703 displays a summary of the consumable status of customer devices. If there are devices requiring consumable replacement among the customer's devices, the consumable status summary 703 displays a message prompting the user to prepare the consumables and the number of such devices. In the example shown in Figure 9, there are no such devices, and the consumable status summary 703 displays a message indicating that preparation for consumable replacement is not yet necessary.

[0109] The Security Status Summary 704 displays a summary of the security status of customer devices. If there are security warnings or errors on customer devices, the Security Status Summary 704 displays a message indicating the error and the number of affected devices. In the example shown in Figure 9, the Security Status Summary 704 displays a message indicating that there is one device with a security warning or error and that there is a device that requires verification.

[0110] The operational status message list 705 displays a list of notifications indicating operational status errors occurring on customer devices. Notification 706 displayed in the operational status message list 705 is an example of a notification, and notification 706 indicates an error where the main unit cover is open on "DeviceB". If there are multiple operational status error notifications, the operational status message list 705 displays them side by side. In the example shown in Figure 9, two devices with errors are notified in the operational status summary 702, and the details of the errors for these two devices are displayed in the operational status message list 705.

[0111] Next, we will describe the UI displayed on the operating status tab 403 of the device details screen 710. The device details screen 710 is a screen that displays the status of one device specified by a customer, among the devices associated with a customer who has logged into the customer website 700. Figure 10 shows an example of the device details screen 710 where the operating status tab 403 is selected and the UI of the operating status tab 403 is displayed. The operating status tab 403 includes the top message 711 of the operating status, error information 712, and error history 713.

[0112] The top status message 711 displays a message indicating the status of the status tab 403. In the example shown in Figure 10, an error has been reported in error information 712, so the top status message 711 displays a message indicating that there is an error that requires user action.

[0113] Error information 712 displays information that notifies the user of errors or warnings indicating that the device is unavailable or that some functions are unavailable. Examples of errors or warnings indicating device unavailable or some functions unavailable include the device cover being open, a paper jam, low toner levels, or a service call error. The information displayed in error information 712 includes, for example, the error details, the date and time the error occurred, and the time elapsed since the error occurred. In the example shown in Figure 10, the device is unable to detect paper and displays a message indicating that there is no paper or that the paper is not loaded correctly.

[0114] Error history 713 displays the details of errors that have occurred in the past. Therefore, error history 713 displays warnings and errors shown in error information 712 that have already been resolved. Error history 713 displays error history information such as the error content, the date and time the error occurred, and the date and time the error was resolved. In the example shown in Figure 10, errors indicating a paper jam and a full paper tray that occurred in the past are displayed in the history.

[0115] Both the device status summary 701 (Figure 9) and the operating status tab 403 (Figure 10) of the device details screen 710 have a UI that displays error information regarding the device's operating status. Specifically, this is the operating status message list 705 in the device status summary 701 and the error information 712 in the operating status tab 403 of the device details screen 710. The information source (API resource) for the information shown in the operating status message list 705 and the error information 712 is the same. The correspondence between UI elements and API resources is shown in Table 3 below. Table 3 is an example of a table that holds the mapping information between UI elements of UI component 320 and API resources of UI component 320 of the device details screen 710. Table 3 is a table that adds a table of mapping information between UI elements of UI component 320 of the device status summary 701 and API resources to Table 2 (mapping information between UI elements of UI component 320 of the device details screen 710). [Table 3]

[0116] The UI element “status-summary-page” exists as a UI component 320 of the device status summary 701. Furthermore, there are four UI elements as child elements of “status-summary-page”. These four child elements are “device-operation-status-box”, “device-consumable-status-box”, “device-security-status-box”, and “operation-alert-message-table”. Here, the API resource for “operation-alert-message-table” is “operation-alert”. Similarly, the API resource for the UI element “operation-alert-table” in the operating status tab 403 of the device details screen 401 is also “operation-alert”. Thus, the API resource for the UI element “operation-alert-message-table” in the device status summary 701 and the API resource for the UI element “operation-alert-table” in the device details screen 401 are identical.

[0117] In this embodiment, when UI elements of different UI components 320 use the same API resource, if the display attribute of at least one of the UI elements is "displayed", it is processed as an API resource to be used. Also, when UI elements of different UI components 320 use the same API resource, if the display attribute of all UI elements is "hidden", it is processed as an API resource not to be used. For example, if the display attribute of at least one of the UI elements "operation-alert-message-table" and "operation-alert-table" is "displayed", the API resource "operation-alert" is used.

[0118] The process flow for displaying the UI component 320 on the customer-facing website 302 is basically the same as in Example 1 (Figure 6). Of these, the differences between the processes S513 to S516 and Example 1 will be explained. First, the notification process for the API resources to be used in S513 and S514 will be explained using Figure 11. Figure 11 is a flowchart of the API resource notification process in Example 2. In Example 1 (Figure 7), only the API resources used by the UI component 320 according to the display attributes of the UI elements were identified and notified to the device state management server 101. In this example, the API resources used and not used by the UI component 320 according to the display attributes of the UI elements are identified and notified to the device state management server 101. Each process shown in Figure 11 is realized when the CPU 201 of the information terminal 104 having a web browser 301 displaying the customer-facing website 302 executes a program for displaying the customer-facing website.

[0119] Steps S601 to S603 are the same as in Example 1. In S604, the UI component control unit 321 refers to the display attribute of the UI element currently being processed among the UI elements included in the page and determines whether the display attribute is "displayed". If the display attribute of the UI element is "displayed", the UI component control unit 321 performs the process in S605. On the other hand, if the display attribute of the UI element is "hidden", the UI component control unit 321 performs the process in S801. If the display attribute is not specified, the process may follow the display attribute of the parent UI element, or a display / hidden setting for when it is not specified may be set in advance and the process may follow that setting.

[0120] In S801, the UI component control unit 321 determines whether the API resource corresponding to the UI element currently being processed has been added to the list of API resources to be used. If the API resource to be processed has already been added to the list of API resources to be used, the process of S606 is performed without adding it to the list of API resources that will not be used as they will be used by other UI elements. On the other hand, if the API resource to be processed has not been added to the list of API resources to be used, the process of S802 is performed.

[0121] In S802, the UI component control unit 321 adds the API resource to be processed to the list of unused API resources. Specifically, in S607, the UI component control unit 321 adds the API resource to be processed to the internal list (list of unused API resources) that it notifies the device state management server 101 of as an unused API resource. However, if the same API resource as the API resource to be processed has already been added to the list of unused API resources, it is not added again.

[0122] If the display attribute of the UI element is determined to be "displayed" in S604, the API resource to be processed is designated as an API resource to be used, similar to the process in S605 of Example 1. That is, the UI component control unit 321 adds the API resource to be processed to the internal list (list of API resources to be used) that it notifies the device state management server 101 of as an API resource to be used in S607. Once the API resource to be processed is added to the list of API resources to be used, the UI component control unit 321 performs the process in S803.

[0123] In S803, the UI component control unit 321 determines whether the API resource to be processed has already been added to the list of unused API resources. If the API resource to be processed has already been added to the list of unused API resources, the UI component control unit 321 performs the process in S804. On the other hand, if the API resource to be processed has not been added to the list of unused API resources, the UI component control unit 321 performs the process in S606. In S804, the UI component control unit 321 removes the API resource to be processed from the list of unused API resources.

[0124] If it is determined in S606 that all UI elements (UI components) included in the page have been processed, the process in S607 is performed. In S607, the UI component control unit 321 notifies the device state management server 101 of the API call request information via the API resource notification unit 325. Specifically, the UI component control unit 321 passes a list of API resources to be used and a list of API resources not to be used to the API resource notification unit 325. The API resource notification unit 325 generates a single list that combines the list of API resources to be used and the list of API resources not to be used. The combined list includes information to identify the API resources and information indicating whether each API resource is used or not. The API resource notification unit 325 calls the API of the device state management server 101 and notifies the device state management server 101 of the API resources as API call request information. The information that the API resource notification unit 325 notifies the device status management server 101 is a list of information that combines the API resource name (API resource name in Table 1) for identifying the API resource and a value indicating whether or not that API resource is in use. If the API resource is in use, the status of the API resource is notified as "Yes," and if the API resource is not in use, the status of the API resource is notified as "No."

[0125] Through the above process, if an API resource for a UI element with the display attribute "displayed" and an API resource for a UI element with the display attribute "hidden" overlap, the API resource can be notified to the device state management server 101 as an API resource to be used. Furthermore, an API resource that only corresponds to a UI element with the display attribute "hidden" can be notified to the device state management server 101 as an API resource that will not be used.

[0126] Next, the processing flow of the event transmission instruction from the device state management server 101 to the device 102 in S515 and S516 in this embodiment will be explained using Figure 12. Figure 12 is a flowchart showing the process of issuing an event transmission instruction in Embodiment 2. Each process shown in Figure 12 is realized by the CPU 201 of the device state management server 101 executing a program stored in the memory (ROM 202, HDD 204, etc.) of the device state management server 101.

[0127] This process is initiated by the device state management server 101 upon receiving an API resource notification (S607) from the API resource notification unit 325 of the UI component 320. In this embodiment, the notification received from the API resource notification unit 325 includes information for identifying the API resource and information indicating whether each API resource is in use. In S611, the API receiving unit 331 of the device state management server 101 obtains the API resource information received as a request from the received API resource notification. The request includes the API resource name and a value indicating whether the resource is in use. The API receiving unit 331 then notifies the event management unit 333 of the API resource information.

[0128] The event management unit 333 performs the processes S612, S811, S613, and S812 for one of the notified API resources. In S612, the event management unit 333 obtains the device event corresponding to one of the notified API resources. Specifically, the event management unit 333 identifies the event corresponding to the API resource using a table (Table 2) which defines the mapping between API resources and their corresponding device events. In this embodiment, once the process in S612 is completed, the process in S811 is performed.

[0129] In S811, the event management unit 333 refers to the API call request information, which is a notification from the API resource notification unit 325, and checks whether the API resource is being used. If the API resource is being used, i.e., if the API resource is being used, the event management unit 333 performs the process in S613. On the other hand, if the API resource is not being used, i.e., if the API resource is not being used, the event management unit 333 performs the process in S812.

[0130] If API resources are not used, in S812, the event management unit 333 generates event instruction information instructing the device 102 to stop sending the event in S615, as described later. The event instruction information includes the event name and the instruction to stop sending. If API resources are used, in S613, the event management unit 333 generates event instruction information instructing the device 102 to start sending the event in S615, as described later. The event instruction information includes the event name and the instruction to start sending.

[0131] In S614, the event management unit 333 determines whether it has processed all notified API resources. If processing of all notified API resources is complete, it proceeds to S615. However, if there are any unprocessed API resources, it returns to S612 and executes the processing from S612 for the unprocessed API resources. In S615, the event management unit 333 sends the event instruction information generated in processing S613 and S812 to device 102. The event instruction information sent here includes the instruction to start sending generated in S613 and the instruction to stop sending generated in S812. As a result of the above processing, device 102 will now notify events for devices corresponding to API resources used to display any UI element. On the other hand, notifications from device 102 will stop for events corresponding to API resources that only correspond to hidden UI elements, i.e., API resources that are not used by any UI element. This makes it possible to instruct device 102 to stop sending events corresponding to unused API resources to the device state management server 101, thereby preventing the acquisition of events corresponding to unused API resources from device 102.

[0132] As described above, according to this embodiment, when the display attribute of the UI component 320 is set to "hidden," event notifications from the device 102 that are no longer needed are stopped. Furthermore, if there are duplicate API resources corresponding to UI elements, control is performed to start event notifications from the device 102 for the API resources corresponding to the displayed UI elements. On the other hand, control is performed to stop event notifications from the device 102 for API resources that only correspond to hidden UI elements. This makes it possible to collect events from the device 102 for API resources even if the API resources corresponding to displayed UI elements and the API resources corresponding to non-displayed UI elements are the same. On the other hand, it is possible to prevent events from being sent from the device 102 for API resources corresponding to hidden UI elements. By controlling the data collected from the device 102 according to the display of the UI, the collection of non-displayed data can be suppressed, reducing communication volume and operating costs, and further enhancing customer data protection.

[0133] (Example 3) Examples 1 and 2 show configurations in which the information used to instruct device 102 to send / stop event notifications is determined by API resources notified from UI component 320. Among the information notified from device 102 to device status management server 101, some information may be received at all times from device 102 without concern regarding customer data protection and communication volume, depending on the data content and amount. For example, the error information displayed on the operating status tab 403 of the device details screen 401 only contains the device's error details, and receiving error information at all times does not raise concerns regarding customer data protection or communication volume. Furthermore, by enabling continuous reception, when the UI component 320 is used on the customer-facing website 302, the error information has already been received, which has the advantage of allowing immediate confirmation of the device's operating status.Therefore, Example 3 describes a configuration in which events that can be received at all times are defined among the events instructed to be sent to device 102, and in the case of events that can be received at all times, the notification is instructed to be sent to device 102 regardless of the specification by UI component 320.

[0134] For continuously received events, the instruction to send event notifications to device 102 is performed when a new target device is added to the management of the device status management server 101. Specifically, this occurs when a customer device is added due to the addition of a target customer, or when a new target device is added to a target customer. The process of instructing the sending of event notifications for continuously received events to device 102, which has been newly added to the management of the device status management server 101, is executed at these triggers.

[0135] The process of sending a transmission instruction for an event that is always receivable from the device state management server 101 to the device 102 will be explained using Figure 13. Figure 13 is a flowchart showing the transmission process for an event that is always receivable. Each process shown in Figure 13 is realized by the CPU 201 of the device state management server 101 executing a program stored in the memory (ROM 202, HDD 204, etc.) of the device state management server 101.

[0136] In S901, the event management unit 333 obtains event information that is constantly received from device 102. Specifically, the event management unit 333 maintains a table (Table 4) that associates the mapping definition of API resources and their corresponding device events with a value indicating whether or not an event is constantly received from device 102. The event management unit 333 obtains events from devices where the constantly received flag column, which is a value indicating whether or not an event is constantly received from device 102, is set to "on".

[0137] Table 4 is an example of a table that holds mapping information between API resources and device events, as well as a continuously received flag. Table 4 is the same as the table in Table 2 that holds the mapping information between API resources and device events, but with the addition of a continuously received flag for each event. [Table 4]

[0138] Events with the Always-On Receive flag set to "on" are events that are always received from device 102, regardless of the specification from UI component 320. On the other hand, if the Always-On Receive flag is "off", events are not always received. In the example shown in Table 4, the events "basic-info-snapshotted", "alert-occurred", and "operator-call-changed" are events that are always received, and the Always-On Receive column is set to "on". The event management unit 333 acquires events with the Always-On Receive flag column set to "on" as always-received events.

[0139] In S902, the event management unit 333 generates event instruction information for one of the continuously received events acquired in S901, instructing the device 102 to begin sending the event in S904, as described later. The event management unit 333 creates a list of events to be instructed to begin sending as event instruction information and adds events to it. The event instruction information includes the event name, which is information to identify the event, and the instruction to start sending.

[0140] In S903, the event management unit 333 determines whether all continuously received events have been processed. If all continuously received events have been processed, it proceeds to S904. On the other hand, if there are any unprocessed continuously received events, it returns to S902 and executes the processing from S902 for the unprocessed events. In S904, the event management unit 333 sends the event instruction information generated in S902 to device 102. As a result, events sent by device 102 in the event instruction information are notified. Through the above processing, by instructing device 102 to start sending continuously received events to the device status management server 101, it becomes possible to manage the acquisition of continuously received events from the device.

[0141] The process of sending event transmission instructions from the device state management server 101 to the device 102 in S515 and S516 when there are events to be received at all times will be explained with reference to Figure 14. Figure 14 is a flowchart showing the process of sending event transmission instructions in Embodiment 3. Each process shown in Figure 14 is realized by the CPU 201 of the device state management server 101 executing a program stored in the memory (ROM 202, HDD 204, etc.) of the device state management server 101. Note that in Figure 14, if a process is the same as in Figures 8 and 12, the same reference numeral is used and the explanation here is omitted.

[0142] In S612, the event management unit 333 obtains the device event corresponding to one of the API resources notified by the device status management server 101. Next, in S911, the event management unit 333 determines whether the event currently being processed is an event that is always received. Specifically, the event management unit 333 refers to a table (Table 4) that holds mapping information between API resources and device events and an always-received flag, and checks the value of the always-received flag for the event. If the value of the always-received flag is "on", which indicates that it is an always-received event, it is determined that it is an event that is always received. If the event to be processed is an event that is always received, the transmission instruction has already been sent to the device 102 as an event that is always received by the process in Figure 13, so there is no need to change the transmission instruction, and the processes in S613 and S812 are not performed, and the process in S614 is performed. On the other hand, if the event currently being processed is not an event that is always received, the process in S811 is performed. The processes from S811 onwards are the same as in Example 2. As shown in Figure 14, for events that are always received, the transmission instruction has already been given, and the device 102 is ready to receive the event. Therefore, no instructions are given to start or stop transmission for events that are always received. On the other hand, for events corresponding to API resources notified from UI component 320 that are not always received events, the same processing as in Examples 1 and 2 is performed. Through this processing, it becomes possible to manage the instructions to start or stop transmission of events to device 102 based on API resource notifications from UI component 320 so as not to include events that are always received.

[0143] In this embodiment, the only server that instructs device 102 to send event notifications is the device state management server 101. However, configurations including other servers are also possible. For example, the device state management server 101 can receive events that other servers instruct device 102 to send via inter-service communication, and set the always-received flag in Table 4 to "on". This allows events used by other services to be controlled as events that are always received. Alternatively, an intermediate server can be set up between multiple servers and device 102. This server can receive event notification transmission instructions for device 102 from multiple servers, and the intermediate server can merge these instructions and send a transmission instruction to device 102.

[0144] As described above, according to Example 3, for events that are always received, when a device becomes a managed device, it is possible to instruct the start of sending events that are always received. Furthermore, event instructions can be given to device 102 that take into account events that are always received, without relying on notifications of API resources by the UI component 320 of the device state management server 101.

[0145] This embodiment includes the following system configuration. (Composition 1) A system including a device management program and a device management service that are executed when a website is accessed via a web browser, A notification means for identifying the API resource to be used and notifying the device management service, according to the display attributes indicating whether to show or hide each of the multiple UI elements provided by the device management program as UI components included in the website, which are set in the display attributes. The system is characterized by having a management means for managing the acquisition of events from devices corresponding to the API resources used in the device management service. (Configuration 2) The notification means obtains an API resource defined as corresponding to the UI element, and if the display attribute set on the UI element is set to display the UI element, it identifies the API resource corresponding to the UI element as the API resource to be used, and notifies the device management service of the API resource to be used. The system according to Configuration 1, characterized in that the management means manages the device so that it can obtain the event by instructing the device to start sending the event corresponding to the API resource to be used to the device management service. (Composition 3) The system according to configuration 1 or 2, characterized in that the notification means notifies the device management service of the API resource to use the API resource when the API resource of a UI element whose display attribute is displayed and the API resource of a UI element whose display attribute is hidden overlap. (Composition 4) The notification means notifies the device management service that it does not use API resources that only correspond to UI elements whose display attribute is hidden, The system according to any one of configurations 1 to 3, characterized in that the management means manages the device so as not to acquire the events by instructing the device to stop sending events corresponding to unused API resources to the device management service. (Composition 5) The system according to any one of claims 1 to 4, characterized in that the management means manages the device so that it can receive events from the device by instructing the device to start sending events that are set to be events that can be continuously received from the device to the device management service. (Composition 6) The system according to Configuration 5, characterized in that the instructions to start or stop sending events corresponding to the API resource to the device management service based on the notification do not include events that can be continuously received from the device. (Composition 7) The system according to any one of configurations 1 to 6, characterized in that the device is an image forming apparatus managed by the device management service via a network, the website is a website that displays the status of the image forming apparatus, and the display attributes are set by a provider that provides the website incorporating the device management program.

[0146] (Other embodiments) The present invention can also be realized by supplying a program that implements one or more of the functions of the above-described embodiments to a system or device via a network or storage medium, and by having one or more processors in the computer of that system or device read and execute the program. It can also be realized by a circuit (e.g., an ASIC) that implements one or more functions.

[0147] Although preferred embodiments of the present invention have been described above, the present invention is not limited to these embodiments, and various modifications and changes are possible within the scope of its gist.

Claims

1. A system including a device management program and a device management service that are executed when a website is accessed using a web browser, A notification means for identifying the API resource to be used and notifying the device management service, according to the display attributes indicating whether to show or hide each of the multiple UI elements provided by the device management program as UI components included in the aforementioned website, The system is characterized by having a management means for managing the acquisition of events from devices corresponding to the API resources used in the device management service.

2. The notification means obtains an API resource defined as corresponding to the UI element, and if the display attribute set for the UI element is set to display the UI element, it identifies the API resource corresponding to the UI element as an API resource to be used, and notifies the device management service of the API resource to be used. The system according to claim 1, characterized in that the management means manages the device so that it can acquire the event by instructing the device to start sending the event corresponding to the API resource to be used to the device management service.

3. The system according to claim 1, characterized in that the notification means notifies the device management service of the API resource to use the API resource when the API resource of a UI element whose display attribute is displayed and the API resource of a UI element whose display attribute is hidden overlap.

4. The notification means notifies the device management service that the API resource does not use API resources that only correspond to UI elements whose display attribute is hidden, The system according to claim 1, characterized in that the management means manages the device so as not to acquire the events by instructing the device to stop sending events corresponding to unused API resources to the device management service.

5. The system according to claim 1, characterized in that the management means manages the device so that it can acquire events by instructing the device to start sending events that are set to be events that can be continuously received from the device to the device management service.

6. The system according to claim 5, characterized in that the instructions to start or stop sending events corresponding to the API resource to the device management service based on the notification do not include events that can be continuously received from the device.

7. The system according to claim 1, wherein the device is an image forming apparatus managed by the device management service via a network, the website is a website that displays the status of the image forming apparatus, and the display attributes are set by a provider that provides the website incorporating the device management program.

8. A method for controlling a system that includes a device management program and a device management service, which are executed when a website is accessed using a web browser, The process involves identifying the API resource to be used according to the display attribute indicating whether to show or hide, which is set for each of the multiple UI elements provided by the device management program as components of the UI displayed on the aforementioned website, and notifying the device management service accordingly. A system control method characterized by comprising the step of managing the acquisition of events from a device corresponding to the API resource used in the device management service.

Images