JP5607556B2 - Information processing apparatus and control method thereof - Google Patents

Description

  The present invention relates to an information processing apparatus of a user interaction type in information processing and a control method thereof.

  In recent years, the design of graphical user interfaces has improved in various fields, and the number of graphical user interfaces using animation, 3D effects, and the like has increased. Especially for embedded devices, display of color illustrations with high image quality and animations using illustrations are desired in order to easily convey the replenishment procedure of consumables and maintenance procedures of embedded devices to the user.

  However, when color illustrations or animations are used, the size of design data incorporated into an embedded device increases. As the size of the design data increases, the time required from the development of the data on the memory to the output to an output device such as a liquid crystal screen increases. As a result, the waiting time of the user from when the user performs an operation until the result is displayed is increased. In particular, when a screen transition in which the entire screen is switched occurs, if the load time from the memory for storing data increases, this directly affects the waiting time of the user.

  In general, the waiting time from when a user performs an operation until the result is returned is an important factor in determining the operability of the user interface. There is a need to keep time within a few hundred milliseconds. There are many techniques for predicting design data to be displayed next on the screen and developing it on a memory in advance as a technique for shortening the waiting time until the result is returned after the user performs an operation.

  For example, Patent Document 1 proposes a method of prefetching a page linked from a page only when it is determined by a Web browser that the user is interested in viewing the displayed page. In this case, whether the user is watching with interest is determined by whether the user has scrolled the screen.

  Also, in Patent Document 2, a web browser predicts the next user operation from the position and movement of the mouse cursor, and as a result, prefetches a page that is determined to be highly likely to be displayed next by the user. A method has been proposed.

  Further, in Patent Document 3, when the transition probability to the screen set in advance in the device or the size of the screen design data exceeds a threshold among screens that may transition next, the screen is prefetched. A method of determining whether or not is proposed.

JP 2006-178513 A Japanese Patent Laying-Open No. 2005-085174 JP 2007-179472 A

  Consider screen transitions in a printer that prints on roll paper using ink. In such a printer, ink and roll paper are consumed every time printing is performed. In view of this, there is a screen that presents a screen that prompts the user to replenish when the ink or roll paper runs out. Considering an electronic dictionary terminal, there is one that presents a screen that prompts charging or battery replacement when the remaining battery level falls below a certain amount.

  However, when the size of the screen design data increases, when the ink is used up, or when the remaining battery level falls below a certain amount, the data is developed on the memory and then output to an output device such as a liquid crystal screen. , User waiting time is increased.

  In addition, when the techniques disclosed in Patent Documents 1 to 3 are used, a large amount of data corresponding to a screen that is not presented is included, resulting in an increase in the amount of data to be developed in the memory.

  Therefore, the present invention suppresses an increase in data to be expanded in a memory, and at the time when a state that triggers a screen transition is detected, the screen transition is executed quickly, and a user's process until a desired screen is presented. The purpose is to shorten the waiting time.

  Therefore, in view of the above problems, the present invention has an object to provide a display technique that can efficiently reduce the waiting time of a user when displaying a screen displayed according to the state of the apparatus on an information processing apparatus or the like. And

  In order to solve the above-described problem, an aspect of the present invention is an information processing apparatus, a storage unit that stores a plurality of screen data, a transition event, and the screen data corresponding to the transition event is converted to the plurality of screen data. Display means for selecting and displaying from, acquisition means for acquiring a parameter value indicating the state of the functional unit of the information processing apparatus, and the parameter based on the acquired parameter value and the screen data being displayed Determining whether or not to cache the screen data related to the cache, and when it is determined to cache, a cache storage means for caching the screen data related to the parameter from the plurality of stored screen data, When a transition event to the screen data cached by the cache storage unit occurs, the display unit displays the key. And displaying with the picture data stored in the Mesh storage means.

  ADVANTAGE OF THE INVENTION According to this invention, when displaying the screen displayed according to the state of an apparatus on information processing apparatus etc., a user's waiting time can be reduced efficiently.

(A) is a block diagram showing the configuration of the information processing apparatus, and (b) is a data flow diagram. 3 is a flowchart illustrating a processing procedure when the system is started in the first embodiment. (A) is a screen transition information, (b) is a screen definition file, (c) is a block diagram of the screen immediately after the device is activated. 6 is a flowchart illustrating a processing procedure while a screen is displayed in the first embodiment. FIG. 3 is a configuration diagram of device status data according to the first embodiment. 4 is a flowchart illustrating details of a process for generating a cache in the first embodiment. (A) is a diagram showing that printing is in progress, (b) is a diagram showing the contents of ink replenishment screen data in the screen cache, and (c) is a diagram showing the display state of the ink replenishment screen. FIG. 3 is a data configuration diagram of a device state in the first embodiment. (A) is a diagram showing that printing is in progress, (b) is a diagram showing the contents of the paper replenishment screen data in the screen cache, and (c) is a diagram showing the display state of the paper replenishment screen. (A) Screen for starting printing, (b) is screen data for CD / DVD tray of screen cache, and (c) is a diagram showing screen display of CD / DVD tray. (A) The block diagram which shows the structure of the information processing apparatus in Embodiment 2, (b) It is a processing function block diagram of the data in the information processing apparatus in Embodiment 2. 10 is a data configuration diagram of a cache instruction table in Embodiment 2. FIG. 10 is a flowchart illustrating details of cache generation processing according to the second embodiment. FIG. 10 is a data configuration diagram of a cache instruction table in the third embodiment. 14 is a flowchart illustrating details of cache generation processing according to the third embodiment. It is a data block diagram of the apparatus state in Embodiment 3. (A) The block diagram which shows the structure of the information processing apparatus in Embodiment 4, (b) The processing function block diagram of the data in the information processing apparatus in Embodiment 4. 14 is a flowchart illustrating details of cache generation processing according to the fourth embodiment. It is a data block diagram of the apparatus state log | history in Embodiment 4. 14 is a flowchart for obtaining a transition probability to a cache target screen in the fourth embodiment. FIG. 10 is a block diagram illustrating a configuration of an information processing device according to an eighth embodiment. FIG. 10 is a data flow diagram illustrating a configuration of an information processing device according to an eighth embodiment. 19 is a flowchart illustrating details of cache generation processing according to the eighth embodiment. 19 is a flowchart illustrating details of cache generation processing according to the eighth embodiment. (A) User operation history, (b) screen transition information, and (c) cache instruction table. It is an apparatus state history in Embodiment 8. 10 shows a screen, a screen cache, and a secondary screen cache that are output to the output device according to the eighth embodiment.

<Embodiment 1>
FIG. 1A is a diagram illustrating an overall configuration regarding display of the information processing apparatus according to the first embodiment. In the first embodiment, the information processing apparatus will be described as a printing apparatus. The CPU 101 controls devices 103 to 110 described below. The CPU 101 accesses the devices 103 to 110 via a bus indicated by 102. A ROM 103 that is a read-only memory is accessed from the CPU 101 via the bus 102. The ROM 103 stores a program code 111 describing the operation of the CPU, a screen definition file 112, and screen transition information 113.

  A screen cache 114 generated by the program code 111 is secured on the RAM 104 which is a readable / writable memory. The screen cache 114 is a part of the RAM 104. The screen cache 114 stores screen data 210. A device state 115 is secured on the RAM 104. The input / output interface 105 receives an input made via an input device such as a keyboard, a mouse, a button, and a dial indicated by 106 and a touch panel indicated by 107. The input / output interface 105 displays / outputs data to / from the CRT, LCD, 108, an output device such as a printer or plotter, and the touch panel 107.

  The external storage device interface 109 inputs / outputs data to / from an external storage device such as HD, FD, CD-ROM, MD, CF shown at 110. In the present embodiment, it is assumed that the program code 111 and each data definition (112 to 113) to be processed are on the ROM 103, and that the temporary storage area (114 to 115) of the data is on the RAM 104. Give an explanation. However, all of these can be arranged on the external storage device 110, and can be loaded from the external storage device 110 onto the RAM 104 and used as necessary. All of these can also be placed on the cache memory of the CPU 101.

  FIG. 1B is a data flow diagram showing how the program code 111 shown in FIG. 1A is related to the constituent elements 112 to 115. The CPU 101 moves the program code 111 on the ROM 103. The input unit 201, the screen control unit 202, the output unit 206, the cache generation unit 207, and the device state management unit 209 are part of the program code 111. The input unit 201 receives user input from the input device 106 or the touch panel 107 via the input / output interface 105. The input unit 201 notifies the screen control unit 202 of an input event by the user and a change event of the device state 115 indicating the state of the functional unit of the printing apparatus notified from the device state management unit 209.

  The screen control unit 202 performs system startup processing and termination processing. The screen control unit 202 determines a screen to be displayed based on the event notified from the input unit 201 and the screen transition information 113. The input unit 201 instructs the output unit 206 to display a screen to be displayed.

  The screen transition information 113 represents the screen ID of the screen data 210 that transitions when an event occurs (reference numeral 501 in FIG. 3B described later). The screen definition file 112 is composed of a plurality of screen data 210. The screen data 210 is information representing the appearance of the screen output to the output unit 206. The screen cache 114 is composed of a plurality of screen data 210. The output unit 206 may output the screen data 210 in the screen definition file 112 or may output the screen data 210 in the screen cache 114. The latter may output the screen data 210 at a higher speed. Is possible. The output unit 206 acquires the screen data 210 instructed from the screen control unit 202 from the screen definition file 112 or the screen cache 114. The output unit 206 outputs the screen data 210 to the touch panel 107 or the output device 108 via the input / output interface 105.

  The cache generation unit 207 stores the screen data 210 in the screen cache 114 based on the screen state file 112 and the device state 115 notified from the device state management unit 209. The device state 115 represents a state of an attached function for operating a consumable or a device from the outside. The device state management unit 209 notifies the screen control unit 202 and the cache generation unit 207 of the device state in accordance with the change in the device state 115. The screen data 210 is output to the output unit 206.

  In the above configuration, the format of the screen data 210 stored in the screen definition file 112 and the screen data 210 stored in the screen cache 114 may be the same or different. For example, the screen definition file 112 may store the screen data 210 in a vector format, and the screen cache 114 may store the screen data 210 in a different raster format.

  Further, the size of the screen cache 114 may change during operation of the printing apparatus. For example, when processing that can be executed at high speed by using many areas of the RAM 104, such as image enlargement, image reduction, and image superposition, is performed, the area of the screen cache 114 is reduced. . Thereby, the printing process can be executed at a higher speed.

  Further, the screen data 210 may be compressed and stored in the screen cache 114. When the screen cache 114 is small, the screen data 210 may not be stored. At this time, by compressing the screen data 210, the screen data 210 can be stored in the screen cache. As a result, the screen can be output at a higher speed than when the screen data 210 is not stored in the screen cache 114.

  FIG. 2 is a flowchart illustrating a processing procedure when the system is started according to the first embodiment. First, in S <b> 301, a startup request for this system is input to the input unit 201 via the input / output interface 105. The activation request for this system is made by the user. When there is an activation request from the user, in step S302, the input unit 201 notifies the screen control unit 202 of an initial screen display event.

  In step S <b> 303, the screen control unit 202 acquires the screen ID of the initial screen from the screen transition information 113. In step S304, the output unit 206 generates screen data 210 of the initial screen using the screen ID of the initial screen acquired in step S303 and the screen definition file 112. In step S305, when the output unit 206 performs processing for displaying the screen data 210 generated in step S304 on the touch panel 107 or the output device 108, the process proceeds to step S306, and the sequence ends.

  FIG. 3A shows the configuration of the screen transition information 113 acquired in S303. The screen transition information 113 includes an item value indicating “transition source screen 401”, an item value indicating “screen transition event 402”, an item value indicating “transition condition 403”, and an item value indicating “transition destination screen 404”. Multiple sets are registered. The transition source screen 401 indicates that a screen transition occurs when this screen is displayed. A screen transition event 402 indicates that a screen transition occurs when this event is notified by the input unit 201 or the device state management unit 209. The transition condition 403 indicates a device state 115 that is a condition for causing screen transition. The transition destination screen 404 indicates screen data output to the output unit 206 after screen transition.

  The row indicated by 405 in FIG. 3A indicates that “SC_Home” of the transition destination screen 404 is output to the output unit 206 when the screen transition event 402 “EV_PowerOn” occurs. “SC_Home” of the transition destination screen 404 is output only when the output unit 206 does not display the screen, that is, “NoScreen”.

  3A indicates that when “EV_PrintStart” of the screen transition event 402 occurs, “SC_Printing” of the transition destination screen 404 is output to the output unit 206. “On the transition destination screen 404” “SC_Printing” is output because the output unit 206 displays “SC_Print” of the transition source screen 401 and the device state 115 is “Tray. Only when isOpen = Closed ”is satisfied.

  FIG. 3B shows the configuration of the screen definition file 112 acquired in S304. Screen ID 501 identifies screen data. The column item indicated by 502 in FIG. 3B is screen data 210 representing data in which the appearance of the screen is defined. The row indicated by 503 in FIG. 3B indicates that screen data whose screen ID 501 is “SC_Home” is stored in the screen data 210 “SC_Home.svg”.

  3C is a data configuration diagram of a screen generated by the flowchart shown in FIG. 2 from the screen data based on the screen transition information shown in FIG. 3A and the screen ID shown in FIG. 3B. is there. The procedure in this case is S302 in FIG. 2, and the input unit 201 notifies the screen control unit 202 of the initial screen display event “EV_PowerOn”. Upon receiving this notification, in step S303, the screen control unit 202 determines to display the transition destination screen 404 “SC_Home” from the screen transition information 113. In step S <b> 305, the output unit 206 outputs the transition destination screen 404 “SC_Home” to the touch panel 107 or the output device 108. The result is the output of the image shown in FIG.

  FIG. 4 is a flowchart showing the processing procedure of the first embodiment while the screen is displayed. In S702, a process of repeatedly executing S703 to S707 is performed. In step S <b> 703, the cache generation unit 207 acquires the device state 115 from the device state management unit 209. After the acquisition, the cache generation unit 207 stores the screen data 210 in the screen cache 114 in S704. The cache generation process will be described later with reference to FIG. In step S <b> 705, the screen control unit 202 determines whether the input unit 201 or the device state management unit 209 has generated an event. If an event has occurred, the process proceeds to S708, and if no event has occurred, the process proceeds to S706. In step S706, the screen control unit 202 stops the processing for a certain period of time. In step S <b> 707, the screen control unit 202 executes the processing subsequent to step S <b> 702 again.

  In step S <b> 708, the screen control unit 202 determines whether a screen transition occurs based on the screen transition information 113. If a screen transition occurs, the process proceeds to S709, and if not, the process proceeds to S706. In step S <b> 709, the screen control unit 202 determines a transition destination screen related to the currently displayed screen based on the screen transition information 113. In step S <b> 710, the output unit 206 determines whether the transition destination screen is stored in the screen cache 114. If it is stored, the process proceeds to S712, and if it is not stored, the process proceeds to S711.

  In step S711, the output unit 206 acquires the screen data 210 from the screen definition file 112 and displays it on the touch panel 107 or the output device 108. Then, the output unit 206 proceeds to step S713 and ends this sequence. In step S712, when the output unit 206 acquires the screen data 210 from the screen cache 114 and outputs the screen data 210 to the touch panel 107 or the output device 108, the output unit 206 proceeds to step S713 and ends this sequence.

  FIG. 5 shows the configuration of the device status 115 acquired in S703. The device state ID 801 identifies the device state. The status value 802 represents the current device status. The row indicated by 803 in FIG. 5 indicates that the device state whose device state ID 801 is “Ink. Magenta” takes a state value 802 of “5”.

  FIG. 6 is a flowchart showing details of the process of generating the cache in S704 in FIG. First, in step S <b> 902, the screen control unit 202 determines whether a screen with the screen ID 501 “SC_Printing” is displayed. If it is displayed, the process proceeds to S903, and if it is not displayed, the process proceeds to S907.

  In step S903, the cache generation unit 207 determines whether the device state status value 802 indicated by “Ink.Magenta” in the device state ID 801 is equal to or less than “5” that is a cache condition. Now, the predetermined threshold value of the state value 802 is set to “5” or less. If it is less than the threshold value of “5”, the ink amount is insufficient, so the process proceeds to step 904. If it exceeds “5”, the remaining amount of ink exceeds the threshold value, so S905. Proceed to

  In S904, when the screen data 210 indicated by “SC_NoMagentaInk” with the screen ID 501 is stored in the screen cache 114 in S904, the cache generation unit 207 proceeds to S910 and ends this sequence. In step S <b> 905, the cache generation unit 207 determines whether the device state state value 802 indicated by “Paper. Length” in the device state ID 801 is equal to or less than a predetermined threshold value “50”. If the cache condition is “50” or less, the amount of paper is insufficient, and the process proceeds to step 906. If it exceeds “50”, the amount of paper is normal and the process proceeds to step 907.

  In step S906, when the cache generation unit 207 stores the screen data 210 indicated by “SC_NoPaper” in the screen ID 501 in the screen cache 114 that performs cache storage, the process proceeds to step S910 and ends this sequence. In step S <b> 907, the screen control unit 202 determines whether the screen indicated by “SC_Print” is displayed with the screen ID 501. If it is displayed, the process proceeds to S908. If it is not displayed, the process proceeds to S910, and this sequence ends.

  In step S908, the cache generation unit 207 determines whether or not the device state status value 802 indicated by “Tray. IsOpened” in the device state ID 801 is the cache condition “Opened”. If it is “Opened”, the process proceeds to Step 909. If it is not “Opened”, the process proceeds to S910, and this sequence is terminated. In step S909, when the cache generation unit 207 stores the screen data 210 indicated by “SC_TrayOpened” in the screen ID 501 in the screen cache 114, the process proceeds to step S910 and ends the sequence.

  FIG. 7 is a diagram showing an example of the data structure of the screen generated in accordance with the flowcharts shown in FIGS. 4 and 6 and the screen cache 114. The screen and screen cache 114 are generated based on the screen transition information shown in FIG. 3A, the screen definition file shown in FIG. 3B, and the device status shown in FIG.

  In FIG. 7A, a screen of “SC_Printing” indicating that printing is being performed with the screen ID 501 is output to the output unit 206. In FIG. 7B, the screen cache 114 stores a screen of “SC_NoMagentaInk” having a screen ID 501 for prompting to replenish magenta ink.

  The operation process related to the above screen will be described with reference to the flowcharts of FIGS. 4 and 6. First, in S703, the device state ID 801 indicates that the device state state value 802 indicated by “Ink.Magenta” is “5”. To do. In S902, since the screen indicated by “SC_Printing” is displayed with the screen ID 501, the process proceeds to S903. In S903, since the status value 802 of the device status indicated by the device status ID 801 “Ink. Magenta” is “5”, the process proceeds to S905. In step S <b> 904, the screen data 210 indicated by “SC_NoMagentaInk” with the screen ID 501 is stored in the screen cache 114. In S705, since no event is notified, the process proceeds to S706. In S706, after sleeping for a predetermined time, the process returns to S703, and the procedure up to S706 is repeated.

  FIG. 7C shows a screen of “SC_NoMagentaInk” in the screen ID 501 output to the output unit 206. This indicates a state after the state value of “Ink.Magenta” of the device state ID 801 becomes “0” and the device state management unit 209 generates “EV_InkChanged” of the screen transition event 402. Based on this screen transition event, the screen is preferentially displayed on the output unit 206.

  The process of the operation related to the above screen will be described with reference to the flowchart of FIG. First, when the screen transition event 402 occurs during the repeated processing from S702 to S707, the apparatus state management unit 209 generates an event in S705, and the process proceeds to S706. In S708, since the screen transition information 113 shown in FIG. 3A transitions to the screen indicated by “SC_NoMagentaInk” with the screen ID 501, the process proceeds to S709. In S710, since the screen indicated by “SC_NoMagentaInk” with the screen ID 501 is stored in the screen cache 114, the process proceeds to S712. In step S <b> 712, the screen data 210 is acquired from the screen cache 114, and the screen data 210 is output to the touch panel 107 or the output device 108.

  FIG. 8 shows a device state different from the device state 115 shown in FIG. 1101 indicates an ink remaining amount that is one of the remaining amounts of consumables. It shows that the value of Magenta is 30. 1102 indicates Paper. Indicating the remaining amount of paper, which is one of the remaining amounts of consumables. It indicates that the value of Length is 30.

  1103 indicates that the tray open which indicates the open / close state of the CD / DVD storage tray, which is one of the attached functions, has a value of Opened. Opened indicates that the CD / DVD storage tray is open.

  9 shows screens generated according to the flowcharts shown in FIGS. 4 and 6 based on the screen transition information shown in FIG. 3A, the screen definition file shown in FIG. 3B, and the device status shown in FIG. It is a figure which shows an example of a data structure with a screen cache.

  FIG. 9A shows that a screen whose screen ID 501 is “SC_Printing” is output to the output unit 206. FIG. 9B shows that a screen “SC_NoPaper” in the screen ID 501 is stored in the screen cache 114.

  The process of the operation related to the above screen will be described with reference to FIGS. Since the screen of “SC_Printing” with the screen ID 501 is displayed in S902, the process proceeds to S903. In S903, since the status value 802 of the device status “Ink.Magenta” in the device status ID 801 exceeds “5”, the process proceeds to S905. In S905, since the status value 802 of the device status “Paper.Length” in the device status ID 801 is “50” or less, the process proceeds to S906. In step S <b> 906, the screen data 210 of “SC_NoPaper” in the screen ID 501 is stored in the screen cache 114.

  If it is assumed in S705 of FIG. 4 that no event has been notified, the process proceeds to S706. After sleeping for a certain time in S706, the process returns to S703 and repeats the process up to S706 again.

  FIG. 9C shows a screen whose screen ID 501 output to the output unit 206 is “SC_NoPaper”. This state is a state after the device state whose device state ID 801 is “Paper.Length” becomes “0” and the device state management unit 209 generates the screen transition event 402 “EV_PaperChanged”.

  If the screen transition event 402 occurs during the repeated processing from S702 to S707, the apparatus state management unit 209 generates an event in S705, and the process proceeds to S708. In S708, the screen transition information 113 shown in FIG. 4 is transitioned to the screen indicated by the screen ID 501 “SC_NoPaper”. In S709, it is determined to transition to “SC_NoPaper”. In S710, since the screen indicated by the screen ID 501 “SC_NoPaperInk” is stored in the screen cache 114, the process proceeds to S712. In step S <b> 712, the screen data 210 is acquired from the screen cache 114 and output to the touch panel 107 or the output device 108.

  10 shows screens and screens generated according to the flowcharts shown in FIGS. 4 and 6 based on the screen transition information shown in FIG. 3A, the screen definition file shown in FIG. 3B, and the device state shown in FIG. It is a figure which shows an example of a data structure with a cache.

  FIG. 10A shows that a screen whose screen ID 501 is “SC_Print” is output to the output unit 206. FIG. 10B shows that a screen whose screen ID 501 is “SC_TrayOpened” is stored in the screen cache 114.

  Since the screen of “SC_Printing” in the screen ID 501 is not displayed in S902, the process proceeds to S907. Since the screen of “SC_Print” in the screen ID 501 is displayed in S907, the process proceeds to S908. In S908, since the device state status value 802 of “Ray.isOpened” in the device state ID 801 is “Opened”, the process proceeds to S909. In step S <b> 909, the screen data 210 of “SC_TrayOpened” in the screen ID 501 is stored in the screen cache 114. Since no event has been notified in S705, the process proceeds to S706. In S706, after sleeping for a certain time, the process returns to S703 and repeats the process up to S706 again.

  FIG. 10C shows a screen in which “EV_PrintStart” of the screen transition event 402 is generated by the input unit 201 by the user's input interface operation, and “SC_TrayOpened” by the screen ID 501 is output to the output unit 206. If the screen transition event 402 occurs during the repeated processing from S702 to S707, the device state management unit 209 detects the event in S705, and the process proceeds to S708.

  In S708, since the tray indicates the open state from the screen transition information shown in FIG. 3A, the screen transitions to the “SC_TrayOpened” screen in the screen ID 501. In S709, the device state management unit 209 transitions to “SC_TrayOpened”. Decide what to do. In S710, since the screen of “SC_TrayOpened” in the screen ID 501 is stored in the screen cache 114, the process proceeds to S712. In step S <b> 712, the screen data 210 is acquired from the screen cache 114 and output to the touch panel 107 or the output device 108.

  As described above, the first embodiment has a configuration including the cache generation unit that loads the design indicator displayed on the screen into the cache and the device state management unit that manages the state of the device. With this configuration, it is possible to pre-read screen design data that determines the display timing according to the state of the device when the screen is highly likely to be displayed.

<Embodiment 2>
In the first embodiment, the method for determining the screen to be cached according to the state of the device has been described. In the first embodiment, an algorithm for determining a screen to be cached is defined in the GUI application. The optimum algorithm for determining the screen to be cached differs depending on the processing speed of the printing apparatus on which the GUI application operates and the configuration of the device attached to the printing apparatus. In the first embodiment, even when it is desired to change only the algorithm for determining the screen to be cached without changing the GUI application, the GUI application needs to be changed. This increases the development cost of the printing apparatus. Therefore, in the second embodiment, a configuration example will be described in which an algorithm for determining a screen to be cached is separated from a GUI application, and contents determined in the flow are tabulated.

  The processing procedure at the time of starting the system according to the second embodiment is shown in the flowchart of FIG. The processing procedure while displaying the screen of the second embodiment is shown in the flowchart of FIG. FIG. 11A is a diagram of an overall system configuration according to the second embodiment. The elements 101 to 115 are the same as those described with reference to FIG. As a new element of this embodiment, there is a cache instruction table 1401.

  FIG. 11B shows the relationship between the newly added cache instruction table 1401 and the components such as the program code described in FIG. The elements 201 to 210 are as described with reference to FIG.

  The cache generation unit 207 refers to the screen definition file 112, the device state 115 acquired from the device state management unit 209, and the cache instruction table 1401, and stores the screen data 210 in the screen cache 114. The cache instruction table 1401 is a set of algorithms for determining a screen to be stored in the cache screen.

  FIG. 12 shows the configuration contents of the cache instruction table 1401. The cache instruction table 1401 is composed of a plurality of cache instructions. As shown in FIG. 12, a parameter value indicated in the device state condition 1602 is specified to be acquired in an output screen condition 1601 that is a display screen condition that is being output. When the value of this parameter looks at the device state condition 1602, the cache target screen 1603 corresponding to this condition is stored in the screen cache.

  The screen indicated by the in-output screen condition 1601 is cached only when the output unit 206 is outputting. Also, the screen data 210 is cached in the screen cache 114 only when the device state condition 1602 is satisfied. The cache target screen 1603 indicates an identification tag of a screen that is cached in the screen cache 114 when the in-output screen condition 1601 is output and the device state condition 1602 is satisfied.

  The cache instruction 1604 indicates that “SC_NoMagentaInk” in the cache target screen 1603 is stored in the screen cache 114. This cache instruction is valid only when “SC_Printing” in the output screen condition 1601 is output and the device state condition 1602 “Ink.Magenta <= 5” is satisfied.

  FIG. 13 is a flowchart showing details of processing in the second embodiment of cache generation in S704 of FIG. In S1702, the cache generation unit 207 repeats S1703 to S1705 as many times as the number of cache instructions included in the cache instruction table 1401.

  In step S1703, the cache generation unit 207 acquires the output screen condition 1601, the device state condition 1602, and the cache target screen 1603 included in the cache instruction acquired in step S1702.

  In step S1704, the cache generation unit 207 determines whether the output unit 206 has output the screen indicated by the in-output screen condition 1601 acquired in step S1703. If it is output, the process proceeds to S1706, and if it is not output, the process proceeds to S1705. In S1705, when all cache instructions have been processed, the process proceeds to S1708, and this sequence ends.

  In step S1706, the cache generation unit 207 determines whether the device state condition acquired in step S1703 is satisfied based on the device state 115. If satisfied, the process proceeds to S1707, and if not satisfied, the process proceeds to S1705. In step S1707, when the cache generation unit 207 stores the screen indicated by the cache target screen 1603 acquired in step S1703 in the screen cache, the process proceeds to step S1708, and this sequence ends.

  The data configuration diagram of the screen generated in accordance with the flowcharts shown in FIGS. 4 and 13 and the screen cache 114 is the same as the data configuration diagram shown in FIG. The screen and screen cache 114 are generated from the screen transition information 113 shown in FIG. 3A, the screen definition file 112 shown in FIG. 3B, the device status 115 shown in FIG. 5, and the cache instruction table 1401 shown in FIG. Has been.

  A state in which the screen having the screen ID 501 of “SC_Printing” is output to the output unit 206 is the same as (a) of FIG. The screen cache 114 stores a screen having the screen ID 501 “SC_NoMagentaInk” as in FIG. 7B.

  The operation relating to this screen will be described with reference to the flowchart of FIG. In step S1703, the output screen condition 1601 “SC_Printing”, the device state condition 1602 “Ink.Magenta <= 5”, and the cache target screen 1603 “SC_NoMagentaInk” are acquired. Since the screen being output in S1704 is “SC_Printing”, the process advances to S1706.

  In S1706, it is determined from the device state 115 shown in FIG. 8 that the device state condition 1602 “Ink.Magenta <= 5” is satisfied, and the process proceeds to S1707. In S 1707, the screen indicated by the cache target screen 1603 “SC_NoMagentaInk” is stored in the screen cache 114.

  As described above, in the second embodiment, by providing a cache instruction table, an algorithm for determining a screen to be cached is made independent of a GUI application such as an event notification from the outside, and contents determined in the flow are stored in a table. Turn into. Thereby, it is possible to change only the algorithm for determining the screen to be cached without changing the GUI application.

<Embodiment 3>
In the embodiments so far, the method of determining the screen to be cached according to the state of the device has been described. However, there are cases where there are a plurality of screen candidates to be cached, the storage capacity of the screen cache 114 is small, and the total amount of data cannot be stored in the screen cache 114. In particular, the storage capacity of the memory mounted on the device needs to be as small as possible in order to reduce development costs. Therefore, the storage capacity of the screen cache that uses a part of the memory may be small.

  Therefore, in the third embodiment, when there are a plurality of screen candidates to be cached and the capacity of the screen cache 114 is small, the screen to be cached is determined based on the priority information stored in the cache instruction table 1401. To do. The processing procedure when the system is started according to the third embodiment is shown in the flowchart of FIG. The processing procedure while displaying the screen of the third embodiment is shown in the flowchart of FIG.

  FIG. 14 is a diagram illustrating the configuration contents of the cache instruction table 1401 according to the third embodiment. The cache priority 1901 determines which of the first cache instruction and the second cache instruction the cache target screen 1603 of which cache instruction is to be preferentially stored in the screen cache 114. Here, it is assumed that the cache priority 1901 has a higher priority as the number is smaller.

  FIG. 15 is a flowchart showing details of the processing in the third embodiment of cache generation in S705 of FIG. Since the processes shown in S2001 to S2006 are the same as the processes shown in S1701 to S1706, which have already been described, description thereof will be omitted.

  In step S2007, the cache generation unit 207 acquires the cache target screen 1603 and the cache priority 1901. In S2008, the cache generation unit 207 repeats the processes from S2009 to S2011 in the order of the priority indicated by the cache priority 1901 by the number of cache target screens 1603 acquired in S2007 (S2005).

  In step S2009, the cache generation unit 207 determines whether the screen data 210 indicated by the cache target screen 1603 acquired in step S2008 can be stored in the screen cache 114. If it can be stored, the processing proceeds to S2010. If it cannot be stored, the process proceeds to S2012, and this sequence ends.

  In step S2010, the cache generation unit 207 stores the screen data 210 indicated by the cache target screen 1603 acquired in step S2008 in the screen cache 114. In step S2011, when the cache generation unit 207 performs processing for the number of cache target screens 1603 acquired in step S2007, the process advances to step S2012, and this sequence ends.

  FIG. 16 shows a device state different from the device state 115 shown in FIGS. The data configuration diagram of the screen generated by the flowcharts shown in FIGS. 4 and 15 and the screen cache 114 is the same as FIG. The screen and the screen cache 114 are generated according to the screen transition information shown in FIG. 3A, the screen definition file shown in FIG. 3B, the device status shown in FIG. 16, and the cache instruction table 1401 shown in FIG.

  Now, it is assumed that the screen cache 114 can store only screen data 210 for one screen. The state in which the screen whose screen ID 501 is “SC_Printing” is output to the output unit 206 is the same as in FIG. The screen cache 114 is the same as FIG. 7B in which a screen whose screen ID 501 is “SC_NoMagentaInk” is stored.

  In S2003, “SC_Printing” in the output screen condition 1601, “Ink.Magenta <= 5” in the device status condition 1602, “SC_NoMagentaInk” in the cache target screen 1603, and “1” in the cache priority 1901 are acquired. In S2004, since the screen being output is “SC_Printing”, the process proceeds to S2006. In S2006, it is determined that “Ink.Magenta <= 5” in the device state condition 1602 from the device state 115 shown in FIG. 16 is satisfied, and the process proceeds to S2007. If “SC_NoMagentaInk” in the cache target screen 1603 and “1” in the cache priority 1901 are acquired in S2007, the process returns to S2002.

  In S2003, “SC_Printing” in the output screen condition 1601 and “Paper.Length <= 50” in the device state condition 1602 are set. Also, 1603 “SC_Paper” in the cache target screen and “2” in 1901 in the cache priority are acquired. In S2004, since the screen being output is “SC_Printing”, the process proceeds to S2006. In S2006, it is determined from the device state 115 that “Paper.Length <= 50” in the device state condition 1602 of FIG. 12 is satisfied, and the process proceeds to S2007. In S2007, “SC_NoPaper” and the priority “2” of the cache priority 1901 in the cache target screen 1603 are acquired.

  In S2008, the processing from S2009 to S2010 is repeated in the order of "SC_NoMagentaInk" on the cache target screen 1603, "SC_NoPaper" on the cache target screen 1603, and the cache priority 1901 in ascending order. In step S2009, since the screen data 210 can be stored in the screen cache, the processing proceeds to step S2010. In S2010, “SC_NoMagentaInk” in the cache target screen 1603 is stored in the screen cache 114. Since the screen data 210 cannot be stored in the screen cache in S2009, the process proceeds to S2012, and the sequence ends.

  As described above, when there are multiple screen candidates to be cached and the screen cache capacity is small, the screen is stored in the screen cache in accordance with the priority information set in advance, so that the screen is prefetched more reliably. It becomes possible.

<Embodiment 4>
In the third embodiment, the screen to be cached is determined based on the priority information stored in the cache instruction table 1401. Since the priority information is preset and constant, when there are a plurality of screens that satisfy the device state condition, one screen with a lower priority is not always cached. Therefore, one screen with a low priority cannot always be output at high speed.

  On the other hand, in the fourth embodiment, when there are a plurality of screen candidates to be cached and the capacity of the screen cache 114 is small, the device status is stored in the memory in time series, and the history of the change in the device status is displayed. An example of determining a screen to be cached based on this will be described.

  The processing procedure at the time of starting the system according to the fourth embodiment is shown in the flowchart of FIG. A processing procedure while displaying the screen of the fourth embodiment is shown in the flowchart of FIG. FIG. 17A is a diagram illustrating a configuration of the entire system of the fourth embodiment. The elements 101 to 116 have already been described in the first embodiment, and the element 1401 has been described in the second embodiment.

  As a new element in the fourth embodiment, there is a device state history 2301. FIG. 17B shows the relationship between the newly added device status history 2301 and the components such as the program code described in FIG. 1 and the cache instruction table 1401 added in FIG. 11B. Indicate. The elements 201 to 210 have been described in the first embodiment, and the cache instruction table 1401 has been described in the second embodiment, so that the description thereof is omitted.

  The cache generation unit 207 acquires the screen data 210 based on the screen definition file 112, the device state 115 acquired from the device state management unit 209, the cache instruction table 1401, and the device state history 2301. The screen data is stored in the screen cache 114. The device state history 2301 represents the history of the device state 115.

  FIG. 18 is a flowchart showing details of the processing in the fourth embodiment of cache generation in S704 of FIG. The processing shown in S2501 to S2506 is the same as the processing described in S1701 to S1706, and the description thereof will be omitted.

  In step S <b> 2507, the cache generation unit 207 acquires the cache target screen 1603, and obtains the transition probability to the cache target screen 1603 based on the screen transition information 113, the device state 115, and the device state history 2301. In S2508, the cache generation unit 207 repeats the processing from S2509 to S2511 for the number of cache target screens 1603 acquired in S2507. This repeating order is repeated in descending order of the transition probability value to the cache target screen 1603 obtained in step S2507.

  The processing indicated by S2509 to S2512 is the same as the processing indicated by S2009 to S2012, and thus description thereof is omitted. FIG. 19 shows the device status history 2301 acquired in S2507. The parameters indicating the device status history are stored in time series. Here, 2601 indicates the device state 115 immediately after the previous operation of the device. Reference numeral 2602 denotes the device state 115 immediately after the device is operated last time. As an example of the fluctuation amount of the device state, it is understood that the numerical value of the state of “Ink. Magenta” is decreased from 3.5 to 2, and the fluctuation amount is 0.5.

  FIG. 20 is a flowchart showing a specific example of the process for obtaining the transition probability to the cache target screen 1603 shown in S2507. Further, the screens generated in accordance with the flowcharts shown in FIGS. 4, 18, and 20 and the data structure of the screen cache 114 are the same as those in FIG. The generated screen and the screen cache 114 are based on the screen transition information shown in FIG. 3A, the screen definition file shown in FIG. 3B, the device status shown in FIG. 16, and the device status history 2301 shown in FIG. .

  Assume that the screen cache 114 can store only screen data 210 for one screen. The state in which the screen whose screen ID 501 is “SC_Printing” is output to the output unit 206 is the same as in FIG. Further, the state in which the screen whose screen ID 501 is “SC_NoPaper” is stored in the screen cache 114 is the same as in FIG. 9B.

  In step S2503, an output screen condition 1601 “SC_Printing”, “Ink.Magenta <= 5” in the device state condition 1602, and “SC_NoMagentaInk” in the cache target screen 1603 are acquired. In S2504, since the screen being output is “SC_Printing”, the process proceeds to S2506. In S2506, it is determined that “Ink.Magenta <= 5” in the device state condition 1602 from the device state 115 shown in FIG. 16 is satisfied, and the process proceeds to S2507.

  In S2702, Ink. If the Magenta fluctuation amount is “−1.5”, in S2703, Ink. The predicted device state 1 of Magenta is obtained as “1.25”. In this case, since the predicted device state 1 is “1.25” in S2704, the condition “Ink.Magenta <= 0” in the transition condition 403 is not satisfied. Accordingly, the process proceeds to S2706.

  In S2706, Ink. When the predicted device state 2 of Magenta is “0.5”, since the predicted device state 2 is “0.5” in S2707, the condition “Ink.Magenta <= 0” in the transition condition 403 is satisfied. Absent. Accordingly, the process proceeds to S2709.

  In S2709, Ink. Magenta's predicted device state 3 is calculated using a calculation formula of “state after previous printing + variation amount * 2”. If the value of the printing paper state after the previous printing is “2” and the fluctuation amount is “−1.5”, these values are substituted into the calculation formula, and the predicted value of the predicted device state 3 is “− 1.0 ". In this case, since the predicted device state 3 is “−1.0” in S2710 and the condition “Ink.Magenta <= 0” in the transition condition 403 is satisfied, the process proceeds to S2711. In S2711, the transition probability to the cache target screen 1603 “SC_NoMagentaInk” is “1”.

  In S2503 of the flowchart of FIG. 18, “SC_Printing” in the output screen condition 1601, “Paper.Length <= 50” in the device state condition 1602, and “SC_Paper” in the cache target screen 1603 are acquired. In S2504, since the screen being output is “SC_Printing”, the process proceeds to S2506. In S2506, it is determined that “Paper.Length <= 50” in the device state condition 1602 from the device state 115 shown in FIG. 16 is satisfied, and the process proceeds to S2507. Then, the transition probability to the cache target screen is calculated.

  Now, in S2701, Paper. It is assumed that the variation amount of the Length parameter is obtained as “−60”. In S2703, assuming that the parameter indicating the state after the previous printing is “40” using a preset calculation formula, Paper. The predicted device state 1 of Length is “10”. At this time, since the predicted device state 1 is “10” in S2704, the condition “Paper.Length <= 0” in the transition condition 403 is not satisfied, and the process advances to S2706.

  In S2706, Paper. If the predicted device state 2 of the length is “−20”, the predicted device state 2 is “−20” in S2707, and the condition of “Paper.Length <= 0” in the transition condition 403 is satisfied. The process proceeds to S2708. In S2708, the transition probability to the cache target screen 1603 “SC_NoPaper” is “2”.

  In S2508, “SC_NoPaper” in the cache target screen 1603 and “SC_NoMagentaInk” in the cache target screen 1603 are repeated in the descending order of transition probabilities.

  In step S2509, since the screen data 210 can be stored in the screen cache, the process advances to step S2510. In step S 2510, “SC_NoPaper” in the cache target screen 1603 is stored in the screen cache 114. In step S2509, since the screen data 210 cannot be stored in the screen cache, the process advances to step S2512 to end the sequence.

  As described above, when there are a plurality of screen candidates to be cached and the capacity of the screen cache is small, the fluctuation amount of the device state is considered based on the history of the device state. As a result, the screen design data for determining the display timing can be prefetched when the possibility of being displayed on the screen is high.

<Embodiment 5>
In the first to fourth embodiments, the device state has been described using the remaining ink value, the remaining number of sheets, and the open / close state of the CD / DVD storage tray. In the fifth embodiment, the screen to be stored in the screen cache 114 is determined based on the state of the network adapter that connects the device to the network and the state of the storage device such as the flash memory connected to the device. An example is disclosed.

  Specifically, the output unit 206 displays a screen for selecting an image to be transmitted to another device, and the device state 115 indicates that the network cable is disconnected. In this case, the cache generation unit 207 can also store the network cable insertion procedure screen in the screen cache 114.

  Further, it is assumed that the output unit 206 displays a scan start screen, and the device status 115 displays that the scan image data cannot be stored because the storage device has a small free space. In this case, the cache generation unit 207 may store a procedure screen in which the storage device is removed and replaced with a different storage device in the screen cache 114.

  As described above, the screen design data that determines the display timing can be displayed on the screen based on the state of the network adapter that connects the device to the network and the state of the storage device such as the flash memory connected to the device. It can be prefetched when it is high.

<Embodiment 6>
Although Embodiment 1 to Embodiment 4 have been described using a printing apparatus as an embodiment, the present invention is not limited to this, and the present invention can also be applied to a photographing apparatus. Specifically, the device state 115 has a function of monitoring the remaining battery level, and when the remaining battery level is low, the cache generation unit 207 stores a screen indicating the charging procedure in the screen cache 114. You can keep it.

  Further, it is assumed that the device state 115 detects that the storage device for storing the captured image has a small free space. At this time, the cache generation unit 207 can store a procedure screen for removing a storage device and replacing it with a different storage device in the screen cache 114.

  As described above, the screen design data for determining the display timing is highly likely to be displayed on the screen, not only for the printing device but also for the photographing device, based on the remaining battery level and the state of the storage device. It becomes possible to read ahead.

<Embodiment 7>
Although Embodiment 1 to Embodiment 5 have been described using a printing apparatus as an embodiment, the present invention is not limited to this and can be applied to a projection apparatus. Specifically, it is assumed that the projection apparatus has a function of monitoring the total use period of the lamp. At this time, when the device state 115 indicates that the total use period of the lamp included in the projection apparatus is close to the lamp endurance time, the cache generation unit 207 stores the screen indicating the lamp replacement procedure in the screen cache 114. Can do.

  Further, it is assumed that the projection apparatus has a function of monitoring the temperature in the projection apparatus. When the device state 115 detects that the temperature in the projection apparatus is higher than a predetermined value, the cache generation unit 207 stores a screen showing a procedure for turning off the projector and cooling it in the screen cache 114. You can also.

  As described above, not only the printing apparatus but also the projection apparatus, the screen design data for determining the display timing based on the lamp usage time and the internal temperature state is prefetched when the possibility of being displayed on the screen is high. It becomes possible to do.

<Eighth embodiment>
When the techniques shown in the first to seventh embodiments are used, a desired screen can be quickly displayed by storing the screen data in the screen cache when the device state satisfies the condition for caching.

  However, when the user performs an operation to display another screen after the screen data is stored in the screen cache, the screen data stored in the screen cache is not used. This causes a wasteful increase in screen cache usage.

  Therefore, in the eighth embodiment, after the screen data is stored in the screen cache, when the probability that the stored screen data is displayed is reduced by a user operation, the screen data is temporarily saved from the screen cache. Let This prevents an increase in screen cache usage.

  In the eighth embodiment, after the probability that the screen data is displayed decreases, when the probability increases again, the saved screen data is stored in the screen cache. Thereby, a desired screen is quickly displayed.

  In the eighth embodiment, the probability that screen data is displayed is determined by detecting a pre-operation start operation that is an operation that is likely to be performed before the user performs an operation. In the eighth embodiment, when the user performs the operation before the operation start, it is determined that the operation is performed immediately after that, and even if the condition that the screen data displayed by the change in the device state is cached is satisfied, The screen data is not stored in the screen cache. In addition, when the screen data displayed due to the change in the device state is stored in the screen cache at the time when the operation before starting the operation is performed, in the eighth embodiment, the screen data is saved from the screen cache.

  Here, as an example of the operation before starting the operation, for example, in the case of an electronic dictionary terminal having a keyboard that can be stored in the terminal body, an operation of pulling out the keyboard can be cited. Further, for example, in the case of a portable terminal including a touch panel and a stylus that operates the touch panel, an operation in which the user takes out the stylus from the case can be given.

  Further, in the eighth embodiment, the probability of the user performing the operation is determined by detecting the operation after the operation that is highly likely to be performed after the user performs the operation. When the user performs the operation before the start of operation after the user performs the operation after the operation is completed, the screen data is stored in the screen cache if the condition that the screen data displayed due to the change of the device condition is cached is satisfied. To do. At this time, the saved screen data is used and the screen data is not read again. As a result, cache processing can be performed quickly.

  In addition, when the user performs the operation before the operation is started, the user performs the operation after the operation is completed, and the screen data displayed by the change of the device state is satisfied after that, the screen data is stored in the screen cache. To store. As a result, it is possible to quickly display the screen displayed by the change in the device state.

  Here, as an example of the operation after the end of the operation, for example, in the case of an electronic dictionary terminal having a keyboard that can be stored in the terminal main body, there is an operation of returning the keyboard from the pulled-out state. In addition, for example, in the case of a portable terminal including a touch panel and a stylus that operates the touch panel, an operation of returning the stylus from a state in which the user has taken out the case can be given.

  Furthermore, in the eighth embodiment, as described above, when the screen data is not stored in the screen cache, the screen data displayed by the user operation is stored in the screen cache. The case where the screen data is not stored in the screen cache includes the time when the screen data is saved from the screen cache. As a result, it is possible to quickly display a screen that is displayed when the user performs an operation.

  FIG. 21 is a diagram illustrating an overall configuration regarding display of the information processing apparatus according to the eighth embodiment. Since each of the elements 101 to 116 has already been described in the first embodiment, a description thereof will be omitted. The element 1401 has been described in the second embodiment, and the element 2301 has been described in the fourth embodiment.

  Here, 2801 is an operation sensor. The motion sensor 2801 detects a user motion 3101.

  FIG. 22 is a data flow diagram according to the eighth embodiment. Reference numeral 2901 denotes a sensor control unit. The sensor control unit 2901 is notified of the user's operation (reference numeral 3101 in FIG. 25A described later) from the operation sensor 2801. This notification is performed every time the motion sensor 2801 detects a user motion 3101.

  Based on the user's action 3101, the sensor control unit 2901 displays an action type (reference numeral 3103 in FIG. 25A described later) indicating whether the user's action 3101 is a pre-operation start action or a post-operation end action. calculate. The sensor control unit 2901 stores the user action 3101, action time (reference numeral 3102 in FIG. 25A described later), and action type 3103 in the user action history 2902. The operation time 3102 is a time when the sensor control unit 2901 is notified of the user's operation 3101 from the operation sensor 2801.

  The cache generation unit 207 determines the screen data 210 to be stored in the screen cache 114 based on the user operation history 2902.

  Reference numeral 2903 denotes a secondary screen cache. The secondary screen cache 2903 is realized by, for example, an external storage device accessible via the external storage device interface 109. In the case where the screen data 210 is stored in the screen definition file 112 and the case where the screen data 210 is stored in the secondary screen cache 2903, the cache generation unit 207 transfers the screen data 210 to the screen cache 114 at a higher speed. Can be stored. Note that the read / write speed to the screen cache 114 is faster than the read / write speed to the secondary screen cache 2903. In some cases, it may be the same.

  FIG. 23 is a flowchart showing details of the processing in the eighth embodiment of cache generation in S704 of FIG.

  In step S <b> 3002, the cache generation unit 207 determines from the user operation history 2902 whether the last user operation is a pre-operation operation. If the last performed operation is a pre-operation start operation, the process proceeds to S3010. If the last action is not a pre-operation start action, the process proceeds to S3003.

  In step S3003, the cache generation unit 207 stores the screen data 210 pointed to by the cache target screen 1603 in the screen cache 114. The details of the processing of S3003 are shown in the flowchart of FIG.

  In step S3004, the cache generation unit 207 refers to the screen transition information 113. Then, a transition destination screen 404 displayed when a screen transition event 402 whose event type is a user operation occurs is acquired. Then, the processing from S3005 to S3009 is repeated by the number of transition destination screens 404.

  In step S3005, the cache generation unit 207 checks whether the screen cache 114 has a free space. If there is a vacancy, the process proceeds to S3027. If there is no free space, the process proceeds to S3017, and this sequence is terminated.

  In S3027, the cache generation unit 207 checks whether the screen data 210 of the transition destination screen 404 acquired in S3003 has already been cached in the screen cache. If already cached, the process advances to step S3009. If not cached, the process proceeds to S3006.

  In step S3006, the cache generation unit 207 checks whether the screen data 210 of the transition destination screen 404 acquired in step S3003 is stored in the secondary screen cache 2903. If stored, the processing proceeds to S3007. If not stored, the process proceeds to S3008.

  In step S3007, the cache generation unit 207 reads the screen data 210 of the transition destination screen 404 stored in the secondary screen cache 2903, and stores the screen data 210 in the screen cache 114.

  In step S <b> 3008, the cache generation unit 207 reads the screen data 210 of the transition destination screen 404 stored in the screen definition file 112 and stores the screen data 210 in the screen cache 114.

  In step S3010, the cache generation unit 207 acquires the transition destination screen 404 that is displayed when the screen transition event 402 whose event type is a user operation occurs. Then, the processes from S3028 to S3016 are repeated for the number of acquired transition destination screens 404.

  In step S3028, the cache generation unit 207 checks whether the screen data 210 of the transition destination screen 404 acquired in step S3010 has already been cached in the screen cache. If already cached, the process advances to step S3016. If not cached, the process advances to step S3011.

  In step S <b> 3011, the cache generation unit 207 confirms whether the screen cache 114 has a free space. If there is a vacancy, the process proceeds to S3013. If there is no space, the process proceeds to S3012.

  In step S <b> 3012, the cache generation unit 207 stores one of the screen data 210 stored in the screen cache 114 in the secondary screen cache 2903. As a result, a free space is created in the screen cache 114.

  In step S3013, the cache generation unit 207 checks whether the screen data 210 of the transition destination screen 404 acquired in step S3010 is stored in the secondary screen cache 2903. If stored, the process advances to step S3014. If not stored, the process proceeds to S3015.

  In step S3014, the cache generation unit 207 reads the screen data 210 of the transition destination screen 404 stored in the secondary screen cache 2903, and stores the screen data 210 in the screen cache 114.

  In step S3015, the cache generation unit 207 reads the screen data 210 of the transition destination screen 404 stored in the screen definition file 112, and stores the screen data 210 in the screen cache 114.

  FIG. 24 is a flowchart showing details of the cache generation processing in S3003 of FIG. The processing from S2501 to S2507 is the same as the processing described in FIG.

  In S3018, the cache generation unit 207 stores, in a variable N, a smaller value among the number of cache target screens 1603 determined to satisfy the cache conditions in S2506 and the maximum amount of screen data 210 that can be stored in the screen cache 114. To do.

  In S3019, the cache generation unit 207 repeats the processing from S3029 to S3025 N times in order from the largest transition probability value obtained in S2507 for the cache target screen 1603.

  In S3029, the cache generation unit 207 checks whether the screen data 210 of the cache target screen 1603 has already been cached in the screen cache. If already cached, the process proceeds to S3025. If not cached, the process proceeds to S3020.

  In step S3020, the cache generation unit 207 checks whether the screen cache 114 has a free space. If there is a vacancy, the process proceeds to S3022. If there is no space, the process proceeds to S3021.

  In step S <b> 3021, the cache generation unit 207 stores one of the screen data 210 stored in the screen cache 114 in the secondary screen cache 2903. As a result, a free space is created in the screen cache 114.

  In step S3022, the cache generation unit 207 checks whether the screen data 210 of the cache target screen 1603 is stored in the secondary screen cache 2903. If it is stored, the process proceeds to S3023. If not, the process proceeds to S3024.

  In step S <b> 3023, the cache generation unit 207 reads the screen data 210 of the cache target screen 1603 stored in the secondary screen cache 2903 and stores the screen data 210 in the screen cache 114.

  In step S <b> 3024, the cache generation unit 207 reads the screen data 210 of the cache target screen 1603 stored in the screen definition file 112 and stores the screen data 210 in the screen cache 114.

  FIG. 25A shows a user operation history 2902 according to the eighth embodiment.

  Reference numeral 3101 denotes a user action detected by the action sensor 2801. 3102 is an operation time indicating a time when the user's operation 3101 occurs. The operation time 3102 is determined based on the time when the sensor control unit 2901 is notified of the user's operation 3101 from the operation sensor 2801. Reference numeral 3103 denotes an operation type indicating whether the user's operation 3101 is an operation before the start of operation or an operation after the end of operation. The sensor control unit 2901 determines the action type 3103 from the user action 3101 based on a predetermined correspondence table between the user action 3101 and the action type 3103.

  FIG. 25B shows screen transition information 113 in the eighth embodiment.

  Reference numeral 3104 denotes an event type representing the type of the screen transition event 402. When the screen transition event 402 is generated by a user operation, the event type 3104 of the screen transition event 402 is a user operation. On the other hand, when the screen transition event 402 occurs due to a change in the device state 115, the event type 3104 of the screen transition event 402 is a device state change.

  FIG. 25C shows a cache instruction table 1401 in the eighth embodiment. FIG. 26A, FIG. 26B, and FIG. 26C show the device state history 2301 in the eighth embodiment, respectively.

  Hereinafter, in the eighth embodiment, a state in which the output result of the output device 108 and the screen data 210 stored in the screen cache 114 change according to the device state 115 and the user's action 3101 will be described. Here, this operation will be described using the user operation history 2902 shown in FIG. 25A, the screen transition information 113 shown in FIG. 25B, and the cache instruction table 1401 shown in FIG. Further, the screen cache 114 used for explanation can store a maximum of two screen data 210.

  First, the state of the output device 108 and the screen cache 114 when the device state history 2301 is the device state history 2301 shown in FIG. 26A and the time 2010/01/01 10:00:00 is shown in FIG. Show. Time 2010/01/01 10:00: 00 is a state immediately after the system shown in the eighth embodiment is activated.

  Reference numeral 3105 denotes SC_Printing screen data 210 output from the output unit 206 to the user via the output device 108. Reference numeral 3106 denotes SC_Detail screen data 210 and SC_Canceled screen data 210 stored in the screen cache 114.

  Hereinafter, the flow of processing in which the SC_Detail screen data 210 and the SC_Canceled screen data 210 are stored in the screen cache 114 will be described in detail with reference to the flowchart of FIG.

  At time 2010/01/01 10:00: 00, the user operation history 2902 is empty. Therefore, in S3002, the cache generation unit 207 determines that the user's last operation performed is not an operation before starting operation, and the process proceeds to S3003.

  In step S3003, the cache generation unit 207 does not store the screen data 210 in the screen cache 114. This is because all the device state conditions 1602 of the cache instruction table 1401 shown in FIG. 25C are not satisfied.

  In step S3004, the cache generation unit 207 determines that the screen data 210 displayed by the user operation is a total of two screen data 210, SC_Detail screen data 210 and SC_Canceled screen data 210. First, the processing from S3005 to S3009 is performed on the screen data 210 of SC_Detail.

  In step S3005, the cache generation unit 207 determines that there is a free space in the screen cache 114.

  In step S <b> 3027, the cache generation unit 207 determines that the SC_Detail screen data 210 is not stored in the screen cache 114. In step S <b> 3006, the cache generation unit 207 determines that the SC_Detail screen data 210 is not stored in the secondary screen cache 2903. In step S <b> 3008, the cache generation unit 207 stores the SC_Detail screen data 210 of the screen definition file 112 in the screen cache 114. Next, the processing from S3005 to S3009 is performed on the SC_Canceled screen data 210.

  In step S3005, the cache generation unit 207 determines that there is a free space in the screen cache 114. In step S <b> 3027, the cache generation unit 207 determines that the SC_Canceled screen data 210 is not stored in the screen cache 114. In step S3006, the cache generation unit 207 determines that the SC_Canceled screen data 210 is not stored in the secondary screen cache 2903. In step S3008, when the cache generation unit 207 stores the SC_Canceled screen data 210 of the screen definition file 112 in the screen cache 114, the processing illustrated in the flowchart of FIG.

  The above is the processing flow in which the SC_Detail screen data 210 and the SC_Canceled screen data 210 are stored in the screen cache 114.

  Next, when the device status history 2301 is the device status history 2301 shown in FIG. 26B, the time 2010/01/01 10:10:05, the output device 108, the screen cache 114, and the secondary screen cache 2903 are shown. As shown in FIG.

  Reference numeral 3107 denotes SC_NoMagentaInk screen data 210 and SC_Detail screen data 210 stored in the screen cache 114. Reference numeral 3108 denotes SC_Canceled screen data 210 saved in the secondary screen cache 2903.

  Hereinafter, the flow of processing in which the screen data 210 indicated by 3107 is stored in the screen cache 114 and the screen data 210 indicated by 3108 is saved in the secondary screen cache 2903 will be described in detail.

  At time 2010/01/01 10:10:05, the user operation history 2902 is empty. Therefore, in S3002, the cache generation unit 207 determines that the user's last operation performed is not an operation before starting operation, and proceeds to S3003.

  In step S <b> 3003, the cache generation unit 207 saves the SC_Canceled screen data 210 in the secondary screen cache 2903, and stores the SC_NoMagentaInk screen data 210 in the screen cache 114. This mechanism will be described with reference to the flowchart of FIG.

  The cache generation unit 207 determines that the cache target screen 1603 satisfying the cache condition is only SC_NoMagentaInk by executing the processing from S2502 to S2505. Also, it is calculated that the transition probability of transition to the cache target screen 1603 that is SC_NoMagentaInk is 1.

  In S3018, the cache generation unit 207 calculates that the value of the variable N is 1. In S3029, the cache generation unit 207 determines that the screen data 210 of SC_NoMagentaInk is not stored in the screen cache 114. In step S3020, the cache generation unit 207 determines that there is no space in the screen cache 114. In step S <b> 3021, the cache generation unit 207 saves the SC_Canceled screen data 210 stored in the screen cache 114 in the secondary screen cache 2903.

  In step S3022, the cache generation unit 207 determines that the screen data 210 of SC_NoMagentaInk is not stored in the secondary screen cache 2903. In step S <b> 3024, the cache generation unit 207 stores the screen data 210 of SC_NoMagentaInk in the screen cache 114. After executing the above processing, the cache generation unit 207 determines that there is no space in the screen cache 114 in S3005, and proceeds to S3017. Then, the process shown in the flowchart of FIG.

  The following is a processing flow in which the screen data 210 indicated by 3107 is stored in the screen cache 114 and the screen data 210 indicated by 3108 is further saved in the secondary screen cache 2903.

  Next, the state of the device state history 2301 shown in FIG. 26C, the state of the output device 108, the screen cache 114, and the secondary screen cache 2903 when the time 2010/01/01 10:10:07 is shown. As shown in FIG.

  Reference numeral 3109 denotes SC_NoPaper screen data 210 and SC_NoMagentaInk screen data 210 stored in the screen cache 114. Reference numeral 3110 denotes SC_Detail screen data 210 and SC_Canceled screen data 210 stored in the secondary screen cache 2903.

  Hereinafter, a process in which the screen data 210 indicated by 3109 is stored in the screen cache 114 and the screen data 210 indicated by 3110 is saved in the secondary screen cache 2903 will be described in detail.

  At time 2010/01/01 10:10:07, the user operation history 2902 is empty. Therefore, in S3002, the cache generation unit 207 determines that the user's last operation performed is not an operation before starting operation, and the process proceeds to S3003.

  In S3003, the cache generation unit 207 stores the screen data 210 in the screen cache 114 because the device state condition 1602 is satisfied. There are three cache target screens 1603 that satisfy the device state condition 1602: SC_NoMagentaInk, SC_NoYellowInk, and SC_NoPaper. Among these, the screen data 210 of SC_NoPaper and the screen data 210 of SC_NoMagentaInk are cached. Further, the SC_Detail screen data 210 is saved in the secondary screen cache 2903. This mechanism is described below.

  In the flowchart shown in FIG. 24, first, in S2507, the transition probabilities to the three cache target screens 1603 are obtained. From the flowchart shown in FIG. 20, the variation amount of SC_NoMagentaInk is “−2.0”, and the transition probability is 2. The variation amount of SC_NoYellowInk is “−0.7”, and the transition probability is 1. The variation amount of SC_NoPaper is “−80”, and the transition probability is 3.

  In S3018, the cache generation unit 207 calculates that the value of the variable N is 2. In S3019, the cache generation unit 207 executes the processing from S3029 onward twice. First, the processing after S3029 is performed on the screen data 210 of SC_NoPaper whose transition probability is 3.

  In step S <b> 3029, the cache generation unit 207 determines that the SC_NoPaper screen data 210 is not stored in the screen cache 114. In step S3020, the cache generation unit 207 determines that there is no space in the screen cache 114. In step S <b> 3021, the cache generation unit 207 saves the SC_Detail screen data 210 in the secondary screen cache 2903.

  In step S3022, the cache generation unit 207 determines that the screen data 210 of SC_NoPaper is not stored in the secondary screen cache 2903. In step S <b> 3024, the cache generation unit 207 stores the SC_NoPaper screen data 210 in the screen cache 114.

  Next, the cache generation unit 207 performs the processing after S3029 on the screen data 210 of SC_NoMagentaInk whose transition probability is 2.

  In S <b> 3029, the cache generation unit 207 determines that the screen data 210 of SC_NoMagentaInk is stored in the screen cache 114. In S3025, since the cache generation unit 207 repeats the processes from S3019 to S3025 twice, the process proceeds to S3026. After executing the above processing, the cache generation unit 207 determines that there is no space in the screen cache 114 in S3005, and proceeds to S3017. Then, the flowchart shown in FIG.

  As described above, the screen data 210 indicated by 3109 is stored in the screen cache 114, and the screen data 210 indicated by 3110 is further saved in the secondary screen cache 2903.

  Next, FIG. 27D shows the state of the output device 108 and the screen cache 114 when the device state history 2301 is the device state history 2301 shown in FIG. 26C and the time 2010/01/01 10:10:15. Show.

  Reference numeral 3111 denotes SC_Detail screen data 210 and SC_Canceled screen data 210 stored in the screen cache 114. Reference numeral 3112 denotes SC_NoPaper screen data 210 and SC_NoMagentaInk screen data 210 saved in the secondary screen cache 2903.

  Hereinafter, a process in which the screen data 210 is stored in the screen cache 114 and the screen data 210 is saved in the secondary screen cache 2903 will be described in detail.

  At time 2010/01/01 10:10:15, the user action history 2902 stores only the user action 3101 whose action type 3103 is the action before the start of operation. Therefore, in S3002, the cache generation unit 207 determines that the last user action is the operation before starting the operation, and proceeds to S3010.

  In step S <b> 3010, the cache generation unit 207 acquires the transition destination screen 404 that is displayed when the screen transition event 402 in which the event type 3104 is a user operation occurs. In this case, the transition destination screen 404 that satisfies the above conditions is SC_Detail and SC_Canceled. The cache generation unit 207 first performs the processing from S3028 on the SC_Detail screen data 210.

  In step S3028, the cache generation unit 207 determines that the SC_Detail screen data 210 is not stored in the screen cache 114. In step S3011, the cache generation unit 207 determines that there is no space in the screen cache 114. In step S3012, the cache generation unit 207 saves the SC_NoPaper screen data 210 stored in the screen cache 114 in the secondary screen cache 2903.

  In step S <b> 3013, the cache generation unit 207 determines that the SC_Detail screen data 210 is stored in the secondary screen cache 2903. In step S <b> 3014, the cache generation unit 207 returns the SC_Detail screen data 210 saved in the secondary screen cache 2903 to the screen cache 114.

  Next, the cache generation unit 207 performs the processing after S3028 on the SC_Canceled screen data 210.

  In step S3028, the cache generation unit 207 determines that the SC_Canceled screen data 210 is not stored in the screen cache 114. In step S3011, the cache generation unit 207 determines that there is no space in the screen cache 114. In step S3012, the cache generation unit 207 saves the screen data 210 of SC_NoMagentaInk stored in the screen cache 114 in the secondary screen cache 2903.

  In step S3013, the cache generation unit 207 determines that the SC_Canceled screen data 210 is stored in the secondary screen cache 2903. In S3014, when the cache generation unit 207 returns the SC_Canceled screen data 210 saved in the secondary screen cache 2903 to the screen cache 114, the processing proceeds to S3017. Then, the flowchart shown in FIG.

  As described above, the screen data 210 indicated by 3111 is stored in the screen cache 114, and the screen data 210 indicated by 3112 is further saved in the secondary screen cache 2903.

  Finally, the state of the device status history 2301 shown in FIG. 26C, the output device 108, the screen cache 114, and the secondary screen cache 2903 when the time 2010/01/01 10:10:25 is shown. Show. This situation is equivalent to FIG.

  Hereinafter, a process in which the screen data 210 indicated by 3109 is stored in the screen cache 114 and the screen data 210 indicated by 3110 is stored in the secondary screen cache 2903 will be described in detail.

  At the time 2010/01/01 10:10:25, two user actions 3101 are stored in the user action history 2902. Of the two user actions 3101, the action type 3103 of the user action 3101 performed last is an action after the end of the operation. Therefore, in S3002, the cache generation unit 207 determines that the user's last action 3101 is not an operation before starting the operation, and proceeds to S3003.

  In S3003, the cache generation unit 207 stores the screen data 210 in the screen cache 114 because the device state condition 1602 is satisfied. At this time, the cache generation unit 207 returns the SC_NoPaper screen data 210 and the SC_NoMagentaInk screen data 210 saved in the secondary screen cache 2903 to the screen cache 114. Further, the screen data 210 of SC_Detail and SC_Canceled is saved in the secondary screen cache 2903. Details of this mechanism are described below.

  First, in the processing from S2502 to S3018, the cache generation unit 207 calculates that the transition probability to SC_NoMagentaInk is 2, the transition probability to SC_NoYellowInk is 1, and the transition probability to SC_NoPaper is 3. In S3018, the cache generation unit 207 calculates that the variable N is 2.

  In step S3019, the cache generation unit 207 first executes the processing from step S3029 on the screen data 210 of SC_NoPaper. In step S <b> 3029, the cache generation unit 207 determines that the SC_NoPaper screen data 210 is not stored in the screen cache 114.

  In step S3020, the cache generation unit 207 determines that there is no space in the screen cache 114. In step S <b> 3021, the cache generation unit 207 saves the SC_Detail screen data 210 in the secondary screen cache 2903.

  In S3022, the cache generation unit 207 determines that the screen data 210 of SC_NoPaper is stored in the secondary screen cache 2903. In step S <b> 3023, the cache generation unit 207 returns the SC_NoPaper screen data 210 saved in the secondary screen cache 2903 to the screen cache 114.

  Next, the cache generation unit 207 performs the processing of S3029 and subsequent steps on the screen data 210 of SC_NoMagentaInk.

  In S3029, the cache generation unit 207 determines that the screen data 210 of SC_NoMagentaInk is not stored in the screen cache 114. In step S3020, the cache generation unit 207 determines that there is no space in the screen cache 114.

  In step S3021, the cache generation unit 207 saves the SC_Canceled screen data 210 in the secondary screen cache 2903. In step S3022, the cache generation unit 207 determines that the screen data 210 of SC_NoMagentaInk is stored in the secondary screen cache 2903.

  In step S <b> 3023, the cache generation unit 207 returns the SC_NoMagentaInk screen data 210 saved in the secondary screen cache 2903 to the screen cache 114. In S3025, since the cache generation unit 207 repeats the processes from S3019 to S3025 twice, the process proceeds to S3026. After executing the above processing, the cache generation unit 207 determines that there is no space in the screen cache 114 in S3005, and proceeds to S3017. Then, the flowchart shown in FIG. 13 ends.

  As described above, the screen data 210 indicated by 3109 is stored in the screen cache 114, and the screen data 210 indicated by 3110 is stored in the secondary screen cache 2903.

  As described above, in the eighth embodiment, the screen data is temporarily saved from the screen cache when the user performs an operation before starting the operation. Therefore, when the probability that the screen data stored in the screen cache is displayed is low, an increase in the usage amount of the screen cache can be suppressed. This free area can be used for caching a screen that is likely to be displayed by the user. Thereby, a screen can be quickly displayed at the time of a user's operation. This has the effect of reducing the operation waiting time of the user.

  If there is an operation after the user's operation is completed, the saved screen data is returned to the screen cache. At this time, the cache processing can be performed at higher speed by accessing the screen data saved in the secondary screen cache. By performing the processing at a high speed, the probability that the device state will change during the cache processing is reduced. Therefore, the probability of promptly displaying the screen when the device state changes increases. This has the effect of reducing the operation waiting time of the user.

  In the processing of S3003 and S3010, the subsequent processing may be executed in order from the screen data 210 that is frequently displayed on the output device. Further, in the processing of S3012 and S3021, the screen data 210 that is not frequently displayed may be sequentially saved in the secondary screen cache 2903.

  This increases the probability that the screen data 210 stored in the screen cache 114 is used for display on the output device 108. This has the effect of reducing the operation waiting time of the user.

  Further, the order of frequent display may be determined in advance, or the order may be determined statistically from the user's operation history. By determining from the user's operation history, the probability that the screen data 210 stored in the screen cache 114 is used for the display of the output device 108 is increased even when the frequently displayed screen data 210 is different for each user. This has the effect of reducing the operation waiting time of the user.

<Other embodiments>
The present invention can also be realized by executing the following processing. That is, software (program) that realizes the functions of the above-described embodiments is supplied to a system or apparatus via a network or various storage media, and a computer (or CPU, MPU, etc.) of the system or apparatus reads the program. It is a process to be executed.

Claims (9)

An information processing apparatus,
Storage means for storing a plurality of screen data;
Display means for detecting a transition event and selecting and displaying screen data for the transition event from the plurality of screen data;
Obtaining means for obtaining a value of a parameter indicating a state of a functional unit of the information processing apparatus;
Based on the acquired parameter value and the screen data being displayed, it is determined whether to cache the screen data related to the parameter, and when it is determined to cache, the plurality of stored screens Cache storage means for caching screen data related to the parameter from the data,
The display means includes
When the transition event to the screen data cached by the cache storage unit occurs, the information is displayed using the screen data stored in the cache storage unit. The cache storage means includes
A table indicating correspondence between screen data being displayed, parameter values as cache conditions, and identification tags of screen data to be cached, and the screen data corresponding to the identification tags is cached by referring to the table The information processing apparatus according to claim 1, wherein: When there are a plurality of screen data to be cached in the cache storage means, and the total amount of the screen data to be stored is larger than the storage capacity of the cache storage means, the plurality of screen data to be cached 3. The information processing apparatus according to claim 1, wherein the plurality of screen data are cached in the order of high priority according to a priority predetermined for each of the screen data. Parameter storage means for storing the parameter values acquired by the acquisition means in time series; and
The cache storage means includes
When there are a plurality of screen data to be cached, the priority of the cache is set for each of the plurality of screen data to be cached based on the fluctuation amount of the parameter stored in the time series by the parameter storage means. The information processing apparatus according to claim 1, wherein the screen data to be cached is cached in order of priority. The value of the parameter is a remaining value of the consumables of the information processing apparatus,
The cache storage means includes
The screen data for displaying that the remaining amount of the consumable item is low is cached when the remaining amount value of the consumable item acquired by the acquiring unit is equal to or less than a predetermined threshold value. 5. The information processing apparatus according to any one of items 1 to 4. The value of the parameter is the remaining number of print sheets,
The cache storage means further caches screen data for displaying that the remaining number of print sheets is small when the remaining number of sheets is equal to or less than a predetermined threshold. 5. The information processing apparatus according to any one of 4. The information processing apparatus includes a CD / DVD storage tray,
The value of the parameter indicating the state of the functional unit is the open / closed state of the CD / DVD storage tray,
The cache storage means further caches screen data for displaying that the CD / DVD storage tray is open when the value of the parameter indicates an open state. 5. The information processing apparatus according to any one of 4. A method for controlling an information processing apparatus,
A storage step in which the storage means stores a plurality of screen data;
A display step of detecting a transition event and selecting and displaying screen data for the transition event from the plurality of screen data; and
An obtaining step for obtaining a value of a parameter indicating a state of a functional unit of the information processing apparatus;
The cache storage means determines whether to cache the screen data related to the parameter based on the acquired parameter value and the screen data being displayed, and if it is determined to cache, the storage A cache storing step of caching screen data related to the parameter from the plurality of screen data,
The display means comprises a step of displaying using the screen data stored in the cache storage step when a transition event to the screen data cached in the cache storage step occurs. Control method.   The program which makes a computer perform each process in control of the information processing of Claim 8.

Images