Patent ID: 12223155

Hereinafter, an embodiment according to aspects of the present disclosures will be described with reference to the drawings.

FIG.1shows a control configuration of an image processing system1according to an embodiment of the present disclosures. The image processing system1is equipped with a PC10, an MFP100, and a router32. It is noted that “MFP” is an abbreviation for a multi-function peripheral.

The PC10is mainly equipped with a CPU12, a storage14, a user IF16, a display18, and a network IF20, which are configured to communicate with each other via an input/output (I/O) port22. It is noted that “IF” is an abbreviation for an interface.

The user IF16typically includes a keyboard and a mouse.

The display18includes a displaying device, such as a liquid crystal display or organic EL display, and a drive circuit to drive the displaying device. When a touch panel system is used as the display18, the user can perform input operations by touching the input buttons on the screen (i.e., the touch panel). Therefore, in such a case, the display18also serves as the user IF16.

The CPU12executes various application programs (hereinafter referred to as “applications”), firmware and the like, including a program for a main process which will be described below referring toFIGS.6A and6B.

The storage14includes a ROM, a RAM, an HDD, an SSD, an optical disc drive and the like. A data storage area28of the storage14is an area where the CPU12stores data necessary for executing the program for the main process program and other programs. A control program area26of the storage14is an area for storing an OS, the program for the main process, and various other applications and firmware.

The network IF20is configured to connect the PC10to a communication network40. The communication network40is a wired or wireless LAN. The network IF20is either a LAN IF or a WLAN IF, or both. In this embodiment, since a router32and the MFP100are connected to the communication network40, the PC10can transmit and receive various data to and from the MFP100via the router32.

The MFP100is mainly equipped with a CPU101, a ROM102, a RAM103and an NVM104. It is noted that “NVM” is an abbreviation for a non-volatile memory.

The CPU101is configured to control the entire operation of the MFP100, and control a printing engine111and a reading engine112via an engine IF110, respectively.

The ROM102is a memory configured to store a control program (including the main process program described below referring toFIG.10) to be executed by the CPU101. The CPU101is configured to retrieve a control program stored in the ROM102and execute various processes. The RAM103is a memory for temporarily storing image data and the like. The RAM103is also used as a storage area for temporarily storing data, signals and the like which are used by the CPU101in executing the control program, or as a work area for data processing. The NVM104is a non-volatile memory for storing setting information and the like.

The MFP100is equipped with a panel105and keys106. The panel105is a touch panel according to the present embodiment, and various screens are displayed on the panel105according to a state of the MFP100. A user of the MFP100can perform input operations by touching the input buttons on the screen. In the present disclosures, an operation of “touching the input buttons on the screen” may also be referred to as an operation of “pressing the input buttons on the screen.” The key106is a hard key, that is, a key formed by hardware. A power switch, a reset switch, numeric keys and the like are examples of the keys106.

Further, the MFP100has a network IF108which is similar to the network IF20of the PC10. Accordingly, the MFP100is capable of transmitting and receiving various data from the PC10as described above.

The MFP100is also equipped with an engine IF110. A printing engine111and a reading engine112are connected to the engine IF110. The printing engine111is a device configured to print an image on a sheet, and has a printing device such as an electrophotographic, inkjet or thermal printing device, or the like. The reading engine112is a device configured to read images formed on a document, and has a reading device such as a CCD, a CIS or the like. The engine IF110is an interface configured to control the printing engine111and the reading engine112.

The MFP100is further equipped with an image processing circuit120. The image processing circuit120is configured to rasterize the image data of a print job and output the image data to the printing engine111. The image processing circuit120is also configured to process the image data read from the document by the reading engine112into digital data. The image data processed into the digital data is transmitted externally via the network IF108or supplied to the printing engine111for output on sheets.

The CPU101, the ROM102, the RAM103, the NVM104, the panel105, the keys106, the USB IF107, the network IF108, the engine IF110and the image processing circuit120are interconnected via a bus130.

FIG.2Ashows an example of the browser screen180displayed on the display18when the user of the PC10starts the browser on the PC10and enters the URL “10.100.100.1” in the URL input field181. The entered URL “10.100.100.1” indicates a location where an EWS, one of the control programs of the MFP100, is stored. The term “EWS” is an abbreviation for embedded web server.

In a page display area182of the browser screen180, a page provided by the EWS is displayed. The page provided by the EWS includes an item pane183and a detail pane184. The page shown inFIG.2Ais an initial page provided by the EWS. When the user of PC10enters a password in a login password entry field182ain this initial page, indicates the login button182bwith a mouse pointer P, and clicks on the login button182bwith the mouse, the user can access a function settings page, provided by the EWS, for setting respective functions of the MFP100.

FIG.2Bshows an example of a browser screen180that is displayed when a “Remote Panel” item183ais clicked among the multiple items listed in the item pane183on the function setting page. The “Remote Panel” item183ais an item used to display the “Remote Panel” in the detail pane184. On the browser screen180of the example shown inFIG.2B, a login authentication screen190is popped up for performing authentication of the user with respect to the “Remote Panel.” It is noted that the login authentication is performed before displaying the “Remote Panel” for the following reasons.

It is noted that the “Remote Panel” is a virtual screen that is generated and displayed as a virtual display of the panel of the device to remotely access a remotely connected device. Inputting an operation to the “Remote Panel” displayed in the detail pane184results in the same operation input to the device to be remotely accessed, which is the panel105of the MFP100in this embodiment. When the “Remote Panel” is displayed on the PC10, any person can freely and remotely access the MFP100from outside via the PC10. Therefore, it is necessary to restrict the users who can view the “Remote Panel.” Therefore, even after logging into the function setting page, further login authentication is required to display the “Remote Panel.”

The logging into the “Remote Panel” is limited to users having administrative privileges (hereinafter referred to as “administrators”). Firstly, the user enters an administrator name in a user name input field190ain the login authentication screen190, and enters an administrator password in a password input field190b. Then, when the user clicks the login button190cwith the mouse, a confirmation screen105ais displayed on the panel105of the MFP100to ask whether the remote operation of the MFP100is to be permitted, as shown inFIG.2C. When the user of the MFP100presses a “Yes” button105alon the confirmation screen105a, the term “Remote Panel” is displayed on the detail pane184.

FIG.3shows an example of the “Remote Panel” displayed on the detail pane184. The “Remote Panel” which is the example shown inFIG.3includes the panel display105bdisplayed on the panel105of the MFP100as well as the key display105cthat virtually displays the keys106of the MFP100. The screen data for displaying the “Remote Panel” is obtained from the EWS. Since the EWS is software as described above, an expression of “obtaining from the EWS” specifically means that the CPU101of the MFP100obtains from the MFP100by executing the software of the EWS. However, such a situation may be simply expressed such that the screen data is “obtained from the EWS.”

A “Refresh Interval” selection field184bis also displayed on the “Remote Panel.” The “Refresh Interval” selection field184bis used to select an interval at which the screen data for displaying the “Remote Panel” is obtained from the EWS. In the example shown inFIG.3, an interval of “ten seconds” is selected. In other words, the PC10outputs a request for obtaining the screen data to the EWS at ten-second intervals even when there is no user operation of the “Remote Panel.”

In the “Remote Panel,” there is also a termination button184ato terminate the “Remote Panel.” The administrator can terminate the “Remote Panel” by clicking on the termination button184a.

FIGS.4A through4Dshow examples of panel displays105dthrough105e′ which are displayed on the panel105of the MFP100, and in particular, concrete examples of animations displayed on the panel105.

FIG.4Ashows the text input screen105dafter a “Fax” icon105b1in the panel display105binFIG.3is pressed to enter a Fax mode. Similarly,FIG.4Bshows a character input screen105d′. The difference between the character input screen105dinFIG.4Aand the character input screen105d′ inFIG.4Bis that the cursor C1 is displayed at the character input position in the former screen105d, while the cursor C1 is not displayed in the latter screen105d′. Since the cursor C1 is displayed with blinking, the character input screen105don which the cursor C1 is displayed and the character input screen105d′ on which the cursor C1 is not displayed are alternately and repeatedly displayed at a particular timing.

FIG.4Cshows the copy screen105eafter the “Copy” icon105b2in the panel display105binFIG.3has been pressed to enter the Copy mode. Similarly,FIG.4Dalso shows a copy screen105e′. The difference between the copy screen105einFIG.4Cand the copy screen105e′ inFIG.4Dis that in the former screen105e, the cursor C2 is displayed at a position where the number of copies is to be input, while in the latter screen105e′, the cursor C2 is not displayed. Since the cursor C2 is also displayed with blinking, the copy screen105eon which the cursor C2 is displayed and the copy screen105e′ on which the cursor C2 is not displayed are alternately and repeatedly displayed at a particular timing.

This blinking displays of the cursors C1 and C2 are animations because it is achieved by alternating between a still image with the cursors C1 and C2 lit and a still image with the cursors C1 and C2 unlit.

FIG.5AtoFIG.5Cshows examples of “copy-in-progress” screens105fto105f′, which are displayed when the “Start” button105elin the copy screen105eofFIG.4Cis pressed. In the “copy-in-progress” screens105fto105f′, the “In-progress” indications I1 to I3 are displayed to indicate that copying is in progress. In the “copy-in-progress” screens I1 to I3, a single-white circle moves among three circles while shifting its position, indicating that copying is in progress. When one of the circles is white, the other circles are black. These in-progress displays I1 to I3 are also animations, since they are realized by switching between still images in which the positions of the white circle in the three circles are the left, the middle, and the right, in sequence at a predetermined timing.

When the “Remote Panel” is displayed on the PC10side, the contents displayed on the “Remote Panel” and those on the panel105of the MFP100are almost the same, as described above. The screen data to display the “Remote Panel” is generated by the MFP100in response to the request from the PC10to obtain the screen data. Since the screen data generated by the MFP100is the same as the screen data to be displayed on the panel105of the MFP100itself, the contents displayed on the “Remote Panel” and the contents displayed on the panel105of the MFP100are almost the same. The reason for using the expression “almost the same” is that, as described above, the “Remote Panel” may include the key display105cthat is not displayed on the panel105.

In a state where the “Remote Panel” is being displayed, if the animations shown inFIGS.4and5above are displayed on the panel105of the MFP100, the same animations are also displayed in the “Remote Panel.” For example, it is assumed that, after the animations shown inFIGS.4A and4B, in which the cursor C1 blinks, is displayed on the panel105, the panel display105dand the panel display105d′ are alternately and repeatedly displayed. If the PC10transmits a request to the MFP100to obtain the screen data repeatedly at a particular timing to display the same animations in the “Remote Panel,” the same animations can be displayed in the “Remote Panel.”

However, in this case, the MFP100must repeatedly generate and transmit the same screen data in response to the request from the PC10to obtain the screen data. Further, in this case, the MFP100must also generate and display the same screen data on the panel105of the MFP100itself. Therefore, in this case, it is necessary to reduce the load on the CPU101of the MFP100since the load on the CPU101may become excessive and cause delays in other processing.

Therefore, in this case, the MFP100generates a plurality of pieces of screen data for displaying each of the plurality of still images constituting the animation only once, and stops generating the same screen data repeatedly so that the load on the CPU101is reduced.

Hereinafter, the control process performed by the image processing system1configured as described above will be described in detail, referring toFIGS.6through15.

FIGS.6A and6Bshow a flowchart illustrating the main process executed by the CPU12of the PC10. The main process is executed by the CPU12after the login authentication is performed in the login authentication screen190ofFIG.2B. In the description of each process, steps are simply denoted as “S.”

InFIGS.6A and6B, the CPU12first executes a remote operation screen display process (S1). The remote control screen refers to the “Remote Panel” displayed in the detail pane184. Therefore, the remote operation screen display process indicates the process of displaying the “Remote Panel” in the detail pane184.

FIG.7shows a detailed procedure of the remote operation screen display process. InFIG.7, first, the CPU12transmits an http(s) request for an initial screen (S21). It is noted that the http(s) request is a request that follows the http(s) protocol. The reason for transmitting the request according to the http(s) protocol in this way is that a destination of the request is the EWS, and it is necessary to transmit a request in accordance with the protocol that the EWS can interpret. It is noted that the http(s) request for the initial screen is input from the network IF20to the network IF108via the communication network40and the router32. Not only the http(s) request for the initial screen, but data transmission from PC10to MFP100is carried out through the same route. Conversely, data transmission from the MFP100to the PC10is performed through the reverse route.

Next, the CPU12receives an http(s) response and virtual screen data which the EWS transmits in response to receipt of the http(s) request for the initial screen (S22). The http(s) response and the virtual screen data are generated and transmitted by an initial screen transmission process (FIG.10) of S63described below.

Next, the CPU12stores an http(s)cgi in the above data storage area28(S23). The http(s)cgi is the various scripts included in the http(s) response. It is noted that the term “cgi” is an abbreviation for a common gateway interface. In this embodiment, a non-operation timer script, a screen data request script, a screen press process script, and a release processing script are generated (see S71to S73inFIG.11). By executing the scripts, the CPU12can perform a non-operation timer, an http(s)cgi request transmission process and the like.

Further, the CPU12displays received virtual screen data in the detail pane184(S24), and after starting a periodic refresh timer (S25), terminates the remote operation screen display process. As a result, the “Remote Panel” as shown inFIG.3is displayed in the detail pane184. It is noted that the periodic refresh timer is a timer to measure a time interval selected in the “Refresh Interval” selection field184b(FIG.3).

Returning toFIGS.6A and6B, the CPU12determines whether the non-operation timer has measured a first period (S2). It is noted that the “first period” is, for example, 0.5 seconds. The non-operation timer is a timer that is instructed to start at the end of the http(s)cgi request execution process (S50), which is described below usingFIG.9. The first period is counted from a particular operation (e.g., a press or release operation) performed by the user of the PC10on the “Remote Panel.”

When it is determined that the non-operation timer has measured the first period (S2: YES), the CPU12executes a screen refresh process (S3), and then proceeds the process to S4. On the other hand, when it is determined that the non-operation timer has not yet measured the first period (S2: NO), the CPU12proceeds the process to S10.

FIG.8shows the detailed procedure of the screen refresh process. InFIG.8, first, the CPU12transmits an http(s) request for screen refresh (S31). Then, the CPU12receives the http(s) response, virtual screen data, and information indicating the number of screens which the EWS transmits in response to receipt of the http(s) request for screen refresh (S32). The received http(s) response, the virtual screen data and the information indicating the number of screens are stored in the data storage area28. It is noted that the http(s) response, the virtual screen data and the number of screens are generated and transmitted in the screen data transmission process in S65ofFIG.10described below. It is noted that the “number of screens” is the number of screens of the generated virtual screen data. The reason for generating and transmitting such number of screens is that when the virtual screen data is screen data for displaying a plurality of still images constituting an animation, the number of screens of the virtual screen data will be plural (seeFIG.4andFIG.5above). Further, it is because the CPU12is configured to differ the process of displaying the virtual screen data received in S32above between a case where the number of screens of the virtual screen data is plural and a case where the number of screens is single.

Next, the CPU12determines whether or not the number of received screens is two or more (S33). When it is determined that the number of received screens is two or more (S33: YES), the CPU12starts a saved screen refresh timer (S34), and then proceeds to S36. It is noted that the “saved screen refresh timer” is a timer for measuring the switching timing (refresh timing) when the virtual screen data having two or more screens is received and stored in the data storage area28, and displayed in the detail pane184while selecting and switching the stored virtual screen data of two or more screens one by one. In this embodiment, a third time (for example, one second) is used as the refresh timing.

On the other hand, when it is determined that the number of screens received was one (S33: NO), the CPU12starts the above periodic refresh timer (S35) and then proceeds to S36.

In S36, the CPU12refreshes the virtual screen, that is, the “Remote Panel” based on the received virtual screen data, and then terminates the screen refresh process. Accordingly, the “Remote Panel” displayed in the detail pane184becomes the same as the current display screen displayed on the panel105of the MFP100.

Returning toFIGS.6A and6B, in S10, the CPU12determines whether the periodic refresh timer has measured the second period. The periodic refresh timer is a timer for measuring the time interval selected in the “Refresh Interval” selection field184b(FIG.3) as described above. The “second period” is, for example, 10 seconds in this embodiment. When it is determined that the periodic refresh timer has measured the second period (S10: YES), the CPU12proceeds to S3above. On the other hand, when it is determined that the periodic refresh timer has not yet measured the second period (S10: NO), the CPU12proceeds the process to S11.

In S11, the CPU12determines whether the saved screen refresh timer has measured the third time. When it is determined that the saved screen refresh timer has measured the third time (S11: YES), the CPU12advances the process to S12. On the other hand, when it is determined that the saved screen refresh timer has not yet measured the third time (S11: NO), the CPU12returns the process to S2above.

In S12, the CPU12switches the virtual screen with the virtual screen data (that is, the saved screen data) received in S32and saved in the data storage area28. When the saved screen refresh timer has started measuring, there are two or more screens of received virtual screen data, i.e., an animation is to be displayed in the “Remote Panel.” The first of the two or more screens of virtual screen data will be displayed in the “Remote Panel” when the saved screen refresh timer is started (see S34and S36inFIG.8above). In S12, the virtual screen data to be displayed next will be displayed in the “Remote Panel.”

In S13, the CPU12starts the saved screen refresh timer. After that, the CPU12advances the process to S4.

For example, when the animation of blinking cursor C1 shown inFIG.4AandFIG.4Bis to be displayed in the “Remote Panel,” firstly, the virtual screen in which the cursor C1 inFIG.4Ais lit is displayed in the “Remote Panel” in S36. Then, the saved screen refresh timer has measured the third time, the virtual screen in which the cursor C1 inFIG.4Bis turned off is displayed in the “Remote Panel” in S12. After that, when the cursor C1 keeps blinking repeatedly at the same position, in response to the saved screen refresh timer measuring the third time, the virtual screen in which the cursor C1 inFIG.4Ais lit is displayed in the “Remote Panel” in S12, and when the saved screen refresh timer reaches the third time, S12is executed again to display the virtual screen in which the cursor C1 is unlit (FIG.4B) is displayed in the “Remote Panel.” Thereafter, the virtual screen with the cursor C1 lit and the virtual screen with the cursor C1 unlit are alternately displayed in the “Remote Panel.”

In S4, the CPU12determines whether a portion inside the virtual screen has been pressed down. When it is determined that a portion inside the virtual screen has been pressed (S4: YES), the CPU12executes the http(s)cgi request execution process (S5), and then proceeds to S6. On the other hand, when it is determined that a portion inside the virtual screen was not pressed (S4: NO), the CPU12skips S5and proceeds the process to S6.

FIG.9shows a detailed procedure of the http(s)cgi request execution process. InFIG.9, first, the CPU12determines whether the non-operation timer is in operation (S41). When it is determined that the non-operation timer is in operation (S41: YES), the CPU12stops the non-operation timer (S42), and then proceeds to S43. On the other hand, when it is determined that the non-operation timer is not in operation (S41: NO), the CPU12skips S42and proceeds to S43.

In S43, the CPU12determines whether the periodic refresh timer is in operation. When it is determined that the periodic refresh timer is in operation (S43: YES), the CPU12stops the periodic refresh timer (S44), and then proceeds to S45. On the other hand, when it is determined that the periodic refresh timer is not in operation (S43: NO), the CPU12skips S44and proceeds to S45.

In S45, the CPU12determines whether the saved screen refresh timer is in operation. When it is determined that the saved screen refresh timer is in operation (S45: YES), the CPU12stops the saved screen refresh timer (S46), and then proceeds to S47. On the other hand, when it is determined that the saved screen refresh timer is not in operation (S45: NO), the CPU12skips S46and proceeds the processing to S47.

The reason for stopping the non-operation timer and the periodic refresh timer as described above is to postpone the execution of the screen refresh process in S3(FIGS.6A and6B) so that the “Remote Panel” screen will not be refreshed until the http(s)cgi request execution process is completed. The reason for stopping the saved screen refresh timer is to postpone the execution of the virtual screen switching process in S12(FIGS.6A and6B), and to prevent the “Remote Panel” screen from being refreshed until the http(s)cgi request execution process is completed.

When there is an icon or a button at the pressed position in the virtual screen, the screen transitions or the color of the button changes. The http(s)cgi request execution process is a process to realize such a change of the state of the display screen in the virtual screen. Therefore, if the screen refresh process or the virtual screen switching process is executed while the http(s)cgi request execution process is being performed, there may be a discrepancy between the virtual screen and the actual screen of the panel105. Steps S42, S44and S46are provided to prevent such a problem.

In S47, the CPU12generates an http(s)cgi request, and in the subsequent S48, the CPU12transmits the generated http(s)cgi request. It is noted that the generated http(s)cgi request includes the screen press information indicating that the screen has been pressed and the coordinates of the pressed position (hereinafter referred to as “pressed coordinates”).

Next, the CPU12receives the http(s)cgi response transmitted by EWS in response to the http(s)cgi request, and executes a process according to the http(s)cgi response (S49). The http(s)cgi response is generated and transmitted in the screen pressing process in S67(FIG.10) described below.

Further, the CPU12starts the non-operation timer (S50), and then terminates the http(s)cgi request execution process. Thereafter, when the non-operation timer has measured the first period (e.g., 0.5 seconds), the screen refresh process (S3ofFIGS.6A and6B) is executed once.

Returning toFIGS.6A and6B, in S6, the CPU12determines whether an indication object has been released. The indication object is an object that is pressed when a portion inside the virtual screen is pressed. In other words, an indication object includes both an object that is meaningful when pressed (e.g., icons, buttons) and an object that is meaningless even if pressed (e.g., a part of a background image).

When it is determined that the indication object has been released (S6: YES), the CPU12executes the http(s)cgi request execution process (S7), and then returns the process to S2above. On the other hand, when it is determined that the indication object has not been released (S6: NO), the CPU12skips S7and returns the process to S2. The http(s)cgi request execution process is the http(s)cgi request execution process shown inFIG.9. It is noted, however, the content of the http(s)cgi request to be generated is different between a case where the http(s)cgi request execution process is executed in S5and a case where the http(s)cgi request execution process is executed in S7. That is, the http(s)cgi request generated in S5contains the screen press information and the like, whereas the http(s)cgi request generated in S7contains the release information indicating that the indication object has been released and the coordinates of the position where the indication object has been released (hereinafter referred to as “release coordinates”).

FIG.10shows the main process performed by the CPU101of the MFP100. InFIG.10, first, the CPU101displays a standby screen on the panel105(S61). The standby screen is, for example, a screen similar to the panel display105bshown inFIG.3.

Next, the CPU101determines whether an http(s) communication, that is, a data communication according to the protocol of http(s) is an http(s) request for the initial screen (S62). When it is determined that the http(s) communication is an http(s) request for the initial screen (S62: YES), the CPU101executes the initial screen transmission process (S63), and then returns the process to S62above.

FIG.11shows a detailed procedure of the initial screen transmission process. InFIG.11, first, the CPU101generates a non-operation timer script (S71). The non-operation timer script is a program that causes the browser to operate the non-operation timer and perform, for example, the process of S2.

Next, the CPU101generates a screen data request script (S72). The screen data request script is a program that causes the browser to perform the screen data request process and to generate an http(s) request containing the screen data request, for example, a screen refresh http(s) request to be sent in S21.

Next, the CPU101generates a screen pressing process script and a releasing process script (S73). The screen pressing process script is a program that causes the browser to perform a screen pressing process. The screen pressing process includes, for example, a determination process of S4and processes S41to S48(FIG.9) contained in S5which is executed when the determination in S4is “YES.” The “Releasing process script” is a program that causes the browser to execute the releasing process which includes, for example, the determination process in S6and the processes S41to S48in S7, which are executed when the determination in the decision in S5is “YES.”

Next, the CPU101reads out the screen data (S74). The screen data is the data representing the screen currently displayed on the panel105of the MFP100. When the MFP100displays a screen on the panel105, the screen data is generated and stored in the RAM103. Then, the screen data is read out and displayed on the panel105. Therefore, in S74, the CPU101reads the screen data from the RAM103.

Next, the CPU101generates an http(s) response and transmits the same together with the read screen data (S75), and then terminates the initial screen transmission process. The http(s) response is a response to the http(s) request for the initial screen in S21(FIG.7). The http(s) response contains the script generated in S71to S73and information indicating that the screen data is transmitted together.

Returning toFIG.10, when it is determined that the communication according to the http(s) is not an initial screen http(s) request (S62: NO), the CPU101determines whether the communication according to the http(s) is a screen refresh http(s) request (S64). When it is determined that the http(s) communication is the screen refresh http(s) request (S64: YES), the CPU101executes the screen data transmission process (S65), and then returns the processing to S62.

FIG.12shows the detailed procedure of the screen data transmission process. InFIG.12, first, the CPU101reads out the screen data and the number of screens (S81). In S81, the CPU101reads the screen data stored in the RAM103in S93(FIG.13) or S105(FIGS.14A and14B) described below. The number of screens may be stored together with the screen data when the CPU101stores the screen data in the RAM103. Of course, such a configuration is only an example and the number of screens may be counted by the CPU101when reading out the screen data without storing the number of screens.

Next, the CPU101generates an http(s) response and transmits the same together with the read screen data and the number of screens (S82), and then terminates the screen data transmission process. The process of S82differs from the process of S75only in that the http(s) response is a response to the scree refresh http(s) request of S31(FIG.8) and in that the number of screens is to be transmitted. Therefore, further explanation will not be provided.

Returning toFIG.10, when it is determined that the communication of http(s) is not the screen refresh http(s) request (S64: NO), the CPU101determines whether the communication of http(s) is an http(s)cgi request containing screen pressing information and the like (S66). When it is determined that the http(s) communication is an http(s)cgi request containing the screen pressing information and the like (S66: YES), the CPU101executes the screen pressing process (S67), and then returns the process to S63.

FIG.13shows the detailed procedure of the screen pressing process. InFIG.13, first, the CPU101determines whether the pressed coordinate is within the area of any button image (S91). When it is determined that the pressed coordinate is within the area of one of the button images (S91: YES), the CPU101switches the button image to an image showing a pressed state (S92). The button image can be, for example, an icon (“Fax” icon105b1, “Copy” icon105b2, etc.) or a button (“Basic1” button, “Custom1” button, etc.). Switching of the pressing mode means, for example, switching of the color of the button image from the color of the non-pressing mode (normal mode) to a different color.

Next, the CPU101generates screen data, stores the same in the RAM103(S93), and then proceeds to S94. The screen data is data for displaying the “Remote Panel.” The screen data stored in the RAM103is read out and used in the screen data transmission process shown inFIG.12.

On the other hand, when it is determined that the pressed coordinate is not within the area of any button image (S91: NO), the CPU101skips S92and S93and proceeds the process to S94.

In S94, the CPU101transmits the http(s)cgi response, and then terminates the screen pressing process.

Returning toFIG.10, when it is judged that the http(s) communication is not an http(s)cgi request containing screen pressing information and the like (S66: NO), the CPU101determines whether the http(s) communication is an http(s)cgi request containing the release information and the like (S68). When it is determined that the http(s) communication is the http(s)cgi request containing the releasing information and the like (S68: YES), the CPU101executes the releasing process (S69), and then returns the processing to S62. On the other hand, when it is determined that the http(s) communication is not the http(s)cgi request containing the releasing information and the like (S68: NO), the CPU101returns the process to S62above.

FIGS.14A and14Bshow the detailed procedure of the releasing process. InFIG.14, first, the CPU101determines whether the release coordinate is within the area of one of the button images (S101). When it is determined that the release coordinate is within the area of any button image (S101: YES), the CPU101stops the screen refresh timer (S102). The screen refresh timer is a timer controlled by the CPU101, and when the count value is stored in a register, thereby instructing the start, the CPU101decrements the count value at a particular timing. When the count value in the register reaches “0,” an interrupt signal is generated and output to the CPU101. In response to receipt of the interrupt signal, the CPU101executes a time-up interrupt process described below with reference toFIG.15.

Next, the CPU101determines whether the button of the button image within which the release coordinate is determined to be included in S101is a button that switches the screen (S103). When it is determined that the button is a button that switches the screen (S103: YES), the CPU101switches the screen display of the panel105to the screen indicated by the button (S104), and then proceeds to S105. The button is, for example, the “Copy” icon105b2in the panel display105binFIG.3. When the “Copy” icon105b2is released, the panel display105bis switched to the copy screen105eshown inFIG.4C.

In S105, the CPU101generates and stores the screen data to be displayed on the “Remote Panel.” When the processing proceeds from S104to S105, the CPU101generates the screen data that is the same as the screen display of the panel105after switching, and stores the screen data in the RAM103in the same manner as in S93. When the screen display of the panel105after switching is, for example, the copy screen105e, the CPU101generates the screen data to display the screen same as the copy screen105eon the “Remote Panel” and stores the same in the RAM103.

On the other hand, when it is determined that the button is not a button to switch the screen (S103: NO), the CPU101determines whether the button is a character input button (S110). When it is determined that the button is not a character input button (S110: NO), the CPU101switches the button image of the button in the display screen of the panel105to a normal state (S111), and then proceeds to S105. As a result, the button image of the button that has been released is switched from the pressed state to the normal state on the panel105.

When it is determined that the button is the character input button (S110: YES), the CPU101displays input characters on the screen (S112) and then proceeds the process to S105. Thus, the input characters are displayed within the screen on the panel105.

On the other hand, when it is determined that the release coordinate is not within the area of any button image (S101: NO), the CPU101proceeds the process from S101to S106. In this case, since the screen data generation and storage process of S105is not executed, the screen data is not transmitted along with the http(s)cgi response generated in S109, which will be described below.

In S106, the CPU101determines whether a periodic screen refresh is necessary for displaying the animation. In this determination, the CPU101determines whether the animation is being displayed on the panel105since, if the animation is being displayed on the panel105, a periodic screen refresh is necessary.

When it is determined that periodic screen refresh is necessary (S106: YES), the CPU101generates and stores the screen data for the animation (S107). For example, in a case of displaying an animation in which the cursor C1 blinks on the panel105as shown inFIG.4AandFIG.4B, the CPU101generates the screen data for the animation in which the cursor C1 is lit as shown inFIG.4Aand the screen data for the animation in which the cursor C1 is unlit as shown inFIG.4Band stores the screen data in the RAM103in S107.

Next, the CPU101sets a count value in the register such that the screen refresh timer times up in one second (S108), and then proceeds the process to S109.

On the other hand, when it is determined that the periodic screen refresh is unnecessary (S106: NO), the CPU101skips S107and S108and proceeds the process to S109.

In S109, the CPU101generates and transmits the http(s)cgi response. Thereafter, the CPU101terminates the releasing process.

For example, when the “Copy” icon105b2is released in the panel display105bofFIG.3, the CPU12of the PC10performs the http(s)cgi request execution process in S7(FIGS.6A and6B). As a result, the CPU12generates an http(s)cgi request indicating that the “Copy” icon105b2has been released (S47inFIG.9above), and transmits the generated http(s)cgi request (S48). The http(s)cgi request generated here contains the release information indicating that the “Copy” icon105b2has been released and the released coordinates. Since the http(s)cgi request transmitted by the CPU12of the PC10to the MFP100includes the release information and the like, when the CPU101of the MFP100receives this http(s)cgi request from the PC10, the CPU101executes the releasing process in S69(FIG.10).

In this releasing process, the CPU101of the MFP100advances the process from S101, S102, S103and S104, in this order, and switches the screen display on the panel105to the copy screen105eshown inFIG.4C. The CPU101of the MFP100further advances the process to S105, and generates and stores the screen data for displaying the copy screen105eon the “Remote Panel.”

Then, the CPU101of the MFP100determines that periodic screen refreshes for animation display are necessary (S106: YES), generates and stores screen data for animation (S107), and sets the screen refresh timer such that the time-up interrupt process is called after one second (S108). Further, the CPU101of the MFP100generates and transmits an http(s)cgi response to the http(s)cgi request which is generated when the “Copy” icon105b2is released (S109).

The CPU12of the PC10receives the http(s)cgi response from the MFP100in S49ofFIG.9, and starts the non-operation timer in S50. When the non-operation timer measures the first period, e.g., 0.5 seconds, the CPU12of the PC10advances the process from S2to S3inFIGS.6A and6B, and executes the screen refresh process. In the screen refresh process ofFIG.8, the CPU12of the PC10advances the process from S31to S32. At this time, in S32, the CPU12of the PC10receives, as the virtual screen data, the screen data for displaying the copy screen105e(i.e., the screen data for displaying the virtual screen on which the cursor C2 is lit) in the “Remote Panel,” and the screen data for displaying the copy screen105e′ shown inFIG.4D(i.e., the virtual screen on which the cursor C2 is unlit) and the information indicating “two” as the number of screens, and store the same in the data storage area28. Then, the CPU12of the PC10advances the process from S33to S34, starts the saved screen refresh timer, and then refreshes the virtual screen (S36). As a result, firstly, a virtual screen showing the copy screen105eis displayed in the “Remote Panel.”

Then, when the saved screen refresh timer measures the third time, e.g., one second, the CPU12of the PC10proceeds the process from S11to S12ofFIGS.6A and6Band switches the virtual screen with the saved screen data. As a result, a virtual screen showing the copy screen105e′ is displayed in the “Remote Panel.” Then, the CPU12of the PC10starts the saved screen refresh timer (S13). Thus, as long as the cursor C is blinking at the same position, the CPU12of the PC10alternately switches between the virtual screen showing the copy screen105eand the virtual screen showing the copy screen105e′ and displays the same in the “Remote Panel” each time the saved screen refresh timer measures the third time.

FIG.15shows the procedure of the time-up interrupt process of the screen refresh timer. InFIG.15, first, the CPU101reads out the screen data for the animation to be displayed next (S121). For example, in a case of displaying the animation shown inFIGS.4C and4Din which the cursor C2 blinks on the panel105, the CPU101generates the screen data for the animation in which the cursor C2 is lit (FIG.4C) and the screen data for the animation in which the cursor C2 is unlit (FIG.4D) and store the data in RAM103in S107(FIGS.14A and14B). Among the screen data for the animation in which the cursor C2 blinks, the screen data for an animation to be displayed first, that is, the screen data for animation in which the cursor C2 is lit, has already been displayed. Therefore, in this case, in S121, the CPU101reads the screen data for animation in which the cursor C2 is unlit.

Next, the CPU101refreshes the screen on the panel105(S122). As a result, the copy screen105e′ shown inFIG.4Dis displayed on the panel105.

In addition, the CPU101sets a count value in the register such that the screen refresh timer will time up in one second (S123), and then terminates the time-up interrupt process of the screen refresh timer.

When the time-up interrupt process of the screen refresh timer is called again, the CPU101reads out the screen data for animation in which the cursor C2 is lit (FIG.4C) in S121, and refreshes the screen on the panel105with the read screen data for animation in S122. As a result, the copy screen105e(FIG.4C) is displayed on the panel105.

Thereafter, the copy screen105eshown inFIG.4Cand the copy screen105e′ shown inFIG.4Dare alternately displayed on the panel105each time the screen refresh timer time-up interrupt process is called.

Thus, according to the time-up interrupt process of the screen refresh timer, once the screen data for animation is generated and stored in the releasing process (S107inFIGS.14A and14B), when the same screen data for animation is repeatedly displayed, the CPU101of the MFP100only reads and displays the stored screen data for animation (S121, S122), and does not generate the same screen data for animation again.

Similarly, when repeatedly displaying the virtual screen of the same screen data for animation in the “Remote Panel,” the CPU12of the PC10only reads and displays the virtual screen data for displaying the screen data for animation transmitted and saved from the MFP100(S36inFIG.8and S12inFIGS.6A and6B), and does not request the MFP100to generate and transmit the virtual screen data for displaying the same screen data for animation again.

According to the embodiment, the measuring time of the periodic refresh timer is unchanged regardless of whether the animation is displayed in the “Remote Panel” or not. Aspects of the present disclosures do not need to be limited to such a configuration. In a case where the animation is displayed in the “Remote Panel,” the measuring time of the periodic refresh timer may be longer than a case where the animation is not displayed in the “Remote Panel.”

In this embodiment, regarding the screen data for the animation, all the plurality of image data for displaying each of the plurality of still images constituting the animation are received (S32) from the MFP100at once in response to transmitting the http(s) request for refreshing the screen to the MFP100(S31inFIG.8). However, aspects of the present disclosures do not need to be limited to such a configuration. The plurality of image data for displaying each of the plurality of still images constituting the animation may be received one by one from the MFP100in response to transmitting the http(s) request for refreshing the screen.

As described above, the image processing system1according to the present embodiment includes the PC10and the MFP100, and the PC10is configured to remotely access the MFP100. The PC10is equipped with the network IF20, the display18, and the CPU12, and the MFP100is equipped with the network IF108, the panel105, and the CPU101.

When the MFP100is remotely connected via the network IF20of the PC10, the CPU12of the PC10periodically transmits a screen refresh request to the MFP100to obtain the screen data from the MFP100to display the screen on the PC10same as the screen displayed on the panel105of the MFP100. Then, the CPU12of the PC10receives the screen data transmitted by the MFP100in response to the screen refresh request, and displays the same screen as the display screen displayed on the panel105of the MFP100on the display18of the PC10.

When the PC10is remotely connected to the MFP100via the network IF108of the MFP100, the CPU101of the MFP100generates the screen data and transmit the same to the PC10in response to receipt of the screen refresh request from the PC10, selects one image at a time from a plurality of still images constituting the animation, and displays the selected one image with sequentially switching the selected one image. Accordingly, after displaying the animation on the panel105of the MFP100, when the same animation is to be continuously displayed on the panel105of the MFP100, the repeatedly generating of the same screen data as the plurality of screen data is stopped after the generating of the plurality of screen data for display on the MFP100.

Thus, in the image processing system1according to the present embodiment, when the PC10is remotely connected via the network IF108of the MFP100, one image is selected from the plurality of still images constituting the animation, and the selected image is sequentially switched while displaying the animation, thereby the animation being displayed on the panel105of the MFP100. Thereafter, when the same animation is to be continuously displayed on the panel105of the MFP100, after multiple screen data for displaying each of the multiple still images constituting the animation on the PC10is generated, repetitive generating of the same screen data is stopped. Therefore, it becomes possible to suppress load to the CPU101from becoming excessive even when the animation is displayed on the MFP100side, to make the movement of the animation closer to the original movement, and also to control the delay in response to the screen data obtaining request from the PC10.

Incidentally, in this embodiment, the PC10is an example of an “information processing device.” The MFP100is an example of an “image processing device.” The CPUs12,101are examples of a “controller.” The display18, panel105are examples of a “display.” The network IFs20,108are examples of a “communication interface.”

When the display screen shown on the panel105of the MFP100is a screen that displays the animation, the CPU12of the PC10increases the time interval for transmitting the periodic screen refresh requests to the MFP100.

According to the above configuration, the CPU101of the MFP100further suppresses the load to the CPU101of the MFP100since the time interval for generating the screen data and transmitting the same to the PC10becomes longer.

The PC10is further provided with the storage14. When the display screen shown on the panel105of the MFP100is a screen that displays an animation, the CPU12of the PC10receives the screen data which is transmitted by the MFP100one screen data at a time from the plurality of screen data in response to the screen refresh request and stores the same in the storage14. When the same animation is displayed on the display18of the PC10, the animation is displayed using the screen data stored in the storage14.

The PC10is further provided with the storage14. When the display screen shown on the panel105of the MFP100is a screen for displaying an animation, the CPU12of the PC10receives all of the plurality of screen data sent by the MFP100at a time in response to the screen refresh request and stores the same in the storage14. When the same animation as the animation is to be displayed on the display18of the PC10, the animation is displayed using the multiple screen data stored in the storage14.

When transmitting multiple screen data, the CPU101of the MFP100also transmits information indicating that multiple screen data are included (S82inFIG.12).

Accordingly, it is convenient since the CPU12of the PC10can easily recognize how many screen data is to be switched and displayed.

When the display screen shown on the panel105of the MFP100is a screen showing animation (S44inFIG.9), the CPU12of the PC10stops periodically transmitting the screen refresh requests to the MFP100.

Accordingly, it is prevented that any discrepancies between the virtual screen and the actual screen of the panel105.

The present disclosures are not necessarily limited to the above embodiment, and various changes can be made without departing from aspects of the present disclosures.

In the above embodiment, the MFP100is used as an example of an image processing device, but the image processing device may be a stand-alone printer, a scanner, or a copier, not necessarily limited to the MFP100.

In the above embodiment, the CPU101has been described as an example of a controller, but the controller may have a CPU and a dedicated circuit. The dedicated circuits may be, for example, an ASIC (Application Specific Integrated Circuit) and FPGA (Field Programmable Gate Array).

In the above embodiment, two screens (seeFIG.4) and three screens (seeFIG.5) are used as examples of screen data for displaying the plurality of still images that constitute the animation, but the number of screens may be greater than three.