Patent Description:
In general, in a case of performing installation processing of a device driver, an operating system (OS) is rebooted and caused to perform initialization processing of the system as a safe way to normally operate the device driver. <CIT> (hereinafter, referred to as PTL <NUM>) describes a method of reducing unnecessary reboot by determining the necessity of reboot in accordance with updated contents in a case of installing a device driver on a computer. <CIT> relates to a mechanism which is activated when a user opts to hibernate their computer rather than switching it off, for determining whether (as a result of, for example, a distribution or installation of software to a computer) there are any outstanding reboot operations for the computer. <CIT> relates to a control method with a determining step of determining whether or not a control program in an information processing apparatus is to be rebooted when a device driver is installed, and a display controlling step of controlling display of a display screen for reboot when it is determined that reboot is required in the determining step. Internet citation http://www. com/whdc/ system/pnppwr/pnp/no_reboot. mspx relates to installing drivers and utilities without rebooting on Microsoft™ Windows™. <CIT> relates to a firmware updating method for efficiently and surely performing the updating of a firmware without impairing a user's convenience.

The present invention in its first aspect provides a control method of an information processing apparatus as specified in claims <NUM> to <NUM>.

The present invention in its first aspect provides an information processing apparatus as specified in claim <NUM>.

The present invention in its first aspect provides a storage medium storing a program causing a computer of an information processing apparatus as specified in claim <NUM>.

Preferred embodiments of the present disclosure are described below in detail with reference to the appended drawings. The following embodiments are not intended to limit the present disclosure according to the scope of claims. Additionally, not all the combinations of the characteristics described in the present embodiments are necessarily required for the means for solving the problems of the present disclosure.

Before describing the present embodiment, conventional installation processing of a device driver is described. In a case of performing the installation processing of the device driver, a general and safe way to normally operate the device driver is to reboot an OS and cause the OS to perform initialization processing of the system. In this case, it can be considered to display on a screen of a computer a selection instruction screen (see <FIG>) for a user to select whether to perform reboot immediately or later when the installer ends.

In a case where the user wants to avoid rebooting, the user makes selection and instructs the computer to reboot after necessary processing ends through the above-described selection instruction screen such that reboot after the installation processing ends is not performed. Such a situation is, for example, a case where the user wants to avoid rebooting as much as possible when the installation processing ends in, for example, a case where a device driver is installed on a computer that operates whole day. On the other hand, for the device driver installation, there is also a case where an operation of the system is guaranteed without reboot depending on conditions.

However, the system on which the device driver is installed displays in a single uniform way a fixed reboot instruction input screen without determination on the necessity of reboot. Accordingly, there is a problem that the user needs to determine the necessity of rebooting the system all by himself/herself. Additionally, there is also a problem that professional knowledge of the OS, the device driver, the service provided by the system, or the like is required to determine the necessity of rebooting the system, and thus it is difficult for a general user to make the determination by himself/herself.

Moreover, if the user operates the computer without proper determination on the necessity of reboot, there is a risk that the system does not operate properly as a result of not rebooting in a case where it is necessary. Furthermore, the user may not be able to determine a case where rebooting is unnecessary, and there is a risk that unnecessary reboot of the system is performed.

Additionally, in the Windows (registered trademark) OS, a function called high-speed start-up is provided from Windows <NUM> (registered trademark). With the high-speed start-up function enabled, in a case of shutting down a Windows PC by a shutdown operation, it is possible to set the PC to hibernation instead of complete shutdown (shutdown to completely power off). With the PC kept in hibernation, the PC can be activated earlier than usual in a case of starting up the PC next time. Note that, in a case where the shutdown operation is performed while the high-speed start-up function is not enabled, complete shutdown is executed.

However, in a case of an OS environment in which the high-speed start-up functions, there is a risk that the installed driver is kept out of updating in a case where the user rejects immediate reboot of the PC proposed by the installer and also performs the shutdown operation. This is because, as described above, even in a case where the shutdown operation is performed, complete shutdown is not executed in a state where the high-speed start-up function is enabled. Note that, in a case where the reboot operation is performed, complete shutdown is executed for reboot even in a case where the high-speed start-up function is enabled. Thus, in the above-described case, as long as the user does not reboot (completely shut down) the PC, updating of the driver is not applied.

Accordingly, in the following embodiments, there is described a method of notifying the user of that it is necessary to "reboot" the PC in the PC in which the high-speed start-up function is in the enabled state to prevent a problem that update installation of the device driver cannot be normally performed.

<FIG> is a block diagram illustrating an example of a configuration of a network system including an information processing apparatus (PC <NUM>). In the system illustrated in <FIG>, the PC <NUM>, a device <NUM>, and a router <NUM> are connected to each other through a network <NUM>. The devices establish communication according to the Transmission Control Protocol/Internet Protocol (TCP/IP) and the User Datagram Protocol (UDP). The network <NUM> is connected with an external network <NUM> through the router <NUM>. The device <NUM> is a peripheral device such as a printer, a copier, a facsimile, or a scanner or is a device provided with multiple functions of the peripheral devices. The PC <NUM> is able to control the device <NUM> by installing a corresponding driver.

The device <NUM> is compatible with the TCP/IP. Additionally, the device <NUM> is compatible with the Web Services on Devices (WSD) that is a standard network protocol of the Windows OS compatible with Universal Plug and Play (UPnP). Moreover, the device <NUM> is also compatible with the Link-Local Multicast Name Resolution (LLMNR) protocol that can perform name resolution of a neighboring network device. The WSD function or the LLMNR function of the device <NUM> allows the user to switch enabling and disabling of the function by directly operating the device <NUM>. The router <NUM> has a Dynamic Host Configuration Protocol (DHCP) server function and allocates an IP address to the PC <NUM> and the device <NUM>.

<FIG> is a hardware configuration diagram of the PC <NUM>. The PC <NUM> includes a monitor <NUM>, a CPU <NUM>, a ROM <NUM>, a RAM <NUM>, an auxiliary storage device <NUM>, a keyboard <NUM>, a pointing device <NUM>, and a network board <NUM>. The constituents are connected to each other through a bus <NUM>. The monitor <NUM> displays a user interface (hereinafter, UI) of an application such as an application <NUM> or the driver. The CPU <NUM> loads a program of the application, the driver, or the like stored in the ROM <NUM> or the auxiliary storage device <NUM> into the RAM <NUM> and executes the loaded program. The ROM <NUM> stores basic software such as BIOS or various programs for implementing processing executed by the PC <NUM>. The RAM <NUM> temporarily stores software such as the application and the driver, or data used by the software. The auxiliary storage device <NUM> is hard disk, for example. The auxiliary storage device <NUM> stores software (a program) such as the OS, the application, the driver, or a variety of modules. The driver stored in the auxiliary storage device <NUM> includes a device driver (a scanner driver, a printer driver, a facsimile driver, or the like) that controls the device <NUM>. Additionally, the driver stored in the auxiliary storage device <NUM> includes a display control driver that controls display on the monitor <NUM>, a keyboard driver that controls the keyboard <NUM>, or a pointing device driver that controls the pointing device <NUM>. Moreover, the driver stored in the auxiliary storage device <NUM> includes a network driver that controls communication of the network board <NUM>. The application stored in the auxiliary storage device <NUM> includes the application <NUM> illustrated in <FIG>. The application <NUM> has a device search function by the TCP/IP. Note that, the application <NUM> may call a module having the search function to cause the module to execute the function. Additionally, the search function and the information setting function may be provided in different modules, respectively. The keyboard <NUM> and the pointing device <NUM> are an input device that inputs an instruction from the user. The network board <NUM> establishes communication with the device through the network.

<FIG> is an example of a hardware configuration in a case where the device <NUM> is a printer. The device <NUM> includes a CPU <NUM>, a ROM <NUM>, a RAM <NUM>, a communication unit <NUM>, a printing unit <NUM>, an operation unit <NUM>, and a display unit <NUM>. The various constituents included in the device <NUM> are connected to each other through a bus <NUM>. The CPU <NUM> is a microprocessor, for example.

The CPU <NUM> functions as a central processing apparatus of the device <NUM>. The CPU <NUM> loads a program stored in the ROM <NUM> into the RAM <NUM> and executes the loaded program to control the communication unit <NUM>, the printing unit <NUM>, the operation unit <NUM>, and the display unit <NUM>. The ROM <NUM> stores various programs for implementing the processing executed by the device <NUM>. The RAM <NUM> is used as a working area of the CPU <NUM>. The RAM <NUM> temporarily stores various data. The communication unit <NUM> establishes communication with another device through the network. The printing unit <NUM> prints image data on a printing medium such as paper, for example.

The operation unit <NUM> includes an input device such as a button or a touch panel. The display unit <NUM> displays a screen for operating the device <NUM> or various pieces of information on the device <NUM>. Note that, in a case where the device <NUM> is a device other than a printer, the device <NUM> includes another constituent instead of the printing unit <NUM> or in addition to the printing unit <NUM>. For example, in a case where the device <NUM> is a scanner, the device <NUM> includes a reading unit that reads an image on a document as another configuration.

<FIG> is a block diagram illustrating a software configuration of the PC <NUM>. As illustrated in <FIG>, the PC <NUM> includes the application <NUM>, a driver INF file <NUM>, a printer driver <NUM>, a scanner driver <NUM>, and a fax driver <NUM>.

The application <NUM> is a driver installer and searches for the device <NUM> connected with the PC <NUM> and displays information on the detected device onto the monitor <NUM>. Then, a driver of a device corresponding to information selected by the user out of the displayed information is installed on the PC <NUM>.

The driver INF file <NUM> includes the model of the device corresponding to the driver (the printer driver <NUM>, the scanner driver <NUM>, or the fax driver <NUM>) installed by the application <NUM>.

The application <NUM> includes a driver installation unit <NUM> and a reboot determination unit <NUM>. The units illustrated in <FIG> are implemented by the CPU <NUM> of the PC <NUM> reading and executing the application <NUM> stored in the auxiliary storage device <NUM>. In the present embodiment, the application <NUM> searches for a device in the same network and displays the detected device on the monitor <NUM> included in the PC <NUM>. On the other hand, in a case where no device can be found in the same network, the application <NUM> displays on the monitor <NUM> the result that no device can be detected.

The driver installation unit <NUM> installs the driver. Note that, the driver installation unit <NUM> installs a different driver depending on the type of the device. For example, in a case where the device is a printer, the application <NUM> installs the printer driver <NUM> on the PC <NUM>. Additionally, in a case where the device is a scanner, the application <NUM> installs the scanner driver <NUM> on the PC <NUM>. Moreover, in a case where the device is a multi-function printer (MFP), the application <NUM> installs the printer driver <NUM>, the scanner driver <NUM>, and the fax driver <NUM> on the PC <NUM>.

The reboot determination unit <NUM> determines the necessity of rebooting the PC <NUM> for installing the device driver. Then, depending on the determination result, the reboot determination unit <NUM> displays a guidance screen to prompt the reboot on the monitor <NUM> of the PC <NUM>. Additionally, the reboot determination unit <NUM> communicates with the device <NUM> and identifies the type of a port that is generatable in the PC <NUM>. A resident app <NUM> is a resident app that notifies the user of a PC reboot guidance at a fixed time interval in a case where the guidance for the user to immediately reboot the PC <NUM> that is displayed by the installer is rejected.

<FIG> are diagrams illustrating an example of a UI screen displayed by the application <NUM>. The screen in <FIG> is displayed while the application <NUM> executes the processing of the driver installation unit <NUM> or the reboot determination unit <NUM>. A during-installation screen <NUM> includes an internal processing status <NUM> indicating the status of the processing. For example, in the middle of the processing of the driver installation unit <NUM> executed by the application <NUM>, a message such as "driver is being installed. " and a progress bar <NUM> are displayed in the internal processing status <NUM>.

<FIG> is a diagram illustrating an installation completion screen <NUM> displayed when the internal processing in <FIG> is completed. For example, in a case where the processing of the driver installation unit <NUM> is completed, an installation completion message <NUM> is displayed in the installation completion screen <NUM>. Note that, the installation completion screen <NUM> may be displayed as a different screen from the during-installation screen <NUM>, or the displayed contents may be changed within the same screen as the during-installation screen <NUM> and the screen may be displayed as the installation completion screen <NUM>. Additionally, on the installation completion screen <NUM>, once an "END" button <NUM> or a × button at the upper right of the screen is pressed by the user, the application <NUM> executes the processing in the reboot determination unit <NUM>.

<FIG> are diagrams illustrating an example of a message box displayed by the application <NUM>.

In a case where it is determined that reboot of the PC <NUM> is necessary as a result of execution of the reboot determination unit <NUM> by the application <NUM>, a PC reboot selection message <NUM> illustrated in <FIG> is displayed. On the other hand, in a case where it is determined that reboot of the PC <NUM> is unnecessary as a result of execution of the reboot determination unit <NUM> by the application <NUM>, the application <NUM> closes the installation completion screen <NUM>.

<FIG> is an example of the message box displayed by the application <NUM>. Specifically, in a case where the high-speed start-up function of the PC <NUM> is in the enabled state and also a "NO" button <NUM> or a × button at the upper right of the screen of the PC reboot selection message <NUM> is pressed by the user, the message box is displayed. This message is a message for notifying the user of that "reboot" is necessary for the PC <NUM> instead of "shutdown" for updating to the latest driver. In other words, this message is a message prompting the user to execute an operation to "reboot" the PC <NUM>. Additionally, in other words, this message is a message notifying the user of that the driver is not updated to the latest driver until "reboot" of the PC <NUM> is performed. Note that, the present message box may include a message notifying the user of that the high-speed start-up function of the PC <NUM> is in the enabled state, for example. This is because, in a PC in which the "high-speed start-up function" is enabled in the system setting of the PC <NUM>, "shut down" is "hibernation", and "complete shutdown" that is required to apply the update installation is not executed. Note that, since "reboot" includes complete shutdown of the PC, the update installation is applied.

<FIG> is an example of a PC reboot notification pop-up <NUM> displayed by the resident app <NUM>. The PC reboot notification pop-up <NUM> is a pop-up displaying a notification to the user by the resident app <NUM> prompting reboot periodically after the user presses an "OK" button <NUM> or a × button at the upper right of the screen in a PC reboot reminding message <NUM>. In a case where the user presses a "reboot now" button <NUM>, the resident app <NUM> ends and the PC <NUM> is rebooted. In a case where the user presses a "reboot later" button <NUM> or a × button at the upper right of the screen, the resident app <NUM> closes the PC reboot notification pop-up <NUM>. Once a certain interval of time (for example, <NUM> minutes) elapses after the resident app <NUM> closes the PC reboot notification pop-up <NUM>, the resident app <NUM> displays the PC reboot notification pop-up <NUM> again. Note that, in a case where the user enables a checkbox <NUM> and presses the "reboot later" button <NUM> in the PC reboot notification pop-up <NUM>, the resident app <NUM> does not display the PC reboot notification pop-up <NUM> again even in a case where the certain interval of time elapses.

<FIG> is a flowchart illustrating processing from the activation to the end of the application <NUM>. The present flowchart is processing executed by the functions provided in the application <NUM>. That is, the processing is implemented by the CPU <NUM> deploying and executing the program stored in the auxiliary storage device <NUM> of the PC <NUM> into the RAM <NUM>. Note that, a sign "S" in the descriptions of each processing means that it is a step in the flowchart, and the same applies to <FIG> and later.

The present flowchart is started by the user executing an update installation operation of the printer driver <NUM>, the scanner driver <NUM>, the fax driver <NUM>, or the like.

In S801, the application <NUM> displays the during-installation screen <NUM>. The application <NUM> then executes driver installation processing. The driver installation processing is performed by the driver installation unit <NUM>. After S801, the application <NUM> switches the UI screen from the during-installation screen <NUM> to the installation completion screen <NUM>. In the installation completion screen <NUM>, once the user presses the "END" button or the × button at the upper right of the screen, the processing proceeds to S802. Note that, when the driver installation processing is completed in <FIG>, the processing may proceed to S802 without displaying the installation completion screen <NUM> in <FIG>.

In S802, the application <NUM> closes the installation completion screen <NUM> (or the during-installation screen <NUM>) and executes reboot guidance processing. Details of the processing in S802 are described later in <FIG>. After S802, the application <NUM> ends the processing of the present flow.

<FIG> is a flowchart illustrating details of the flow of the reboot guidance processing in <FIG>. First, in S901, the reboot determination unit <NUM> determines the necessity of rebooting the PC <NUM> to apply the updated contents as a result of installation of the driver through the driver installation processing. In this process, the determination on the necessity of reboot may be made by the reboot determination unit <NUM> obtaining "information on necessary PC reboot", which is created based on whether installation of the driver was necessary for the past similar update processing, from the PC <NUM>, for example. If it is determined that reboot of the PC is unnecessary (if it is determined as NO in S901), the reboot determination unit <NUM> ends the processing in <FIG>. On the other hand, if reboot of the PC <NUM> is necessary (if it is determined as YES in S901), the processing proceeds to S902.

In S902, the reboot determination unit <NUM> displays the PC reboot selection message <NUM>. In S903, if the user presses a "YES" button <NUM> in the PC reboot selection message <NUM>, the reboot determination unit <NUM> proceeds to S904 and executes immediate reboot of the PC <NUM>. After S904, the reboot determination unit <NUM> ends the present flow.

On the other hand, in S903, if the user presses the "NO" button <NUM> or the × button at the upper right of the screen in the PC reboot selection message <NUM>, the processing proceeds to S905.

In S905, the reboot determination unit <NUM> determines whether the high-speed start-up function of the PC <NUM> is enabled. The determination may be made by the reboot determination unit <NUM> obtaining from the PC <NUM> "high-speed start-up function state information" in which the state of the high-speed start-up function in the current PC <NUM> is described, for example. In S905, if the high-speed start-up function of the PC <NUM> is in the disabled state or not supported, the reboot determination unit <NUM> ends the present flow. On the other hand, in S905, if the high-speed start-up function of the PC <NUM> is enabled, the processing proceeds to S906.

In S906, the reboot determination unit <NUM> displays the PC reboot reminding message <NUM> on the monitor <NUM>. Once the user presses the "OK" button <NUM> or the × button at the upper right of the screen in the PC reboot reminding message <NUM>, the reboot determination unit <NUM> closes the PC reboot reminding message <NUM>. After the PC reboot reminding message <NUM> is closed in S906, in S907, the reboot determination unit <NUM> registers on a registry in the PC <NUM> current clock time information for the resident app <NUM> to periodically display the PC reboot notification pop-up <NUM>.

In S908, the reboot determination unit <NUM> installs the resident app <NUM>. After the installation processing of the resident app <NUM>, the resident app <NUM> is activated, and the start-up registration or the service registration of the OS is performed. Thus, resident activation is implemented. After S908, the reboot determination unit <NUM> ends the present flow.

<FIG> is a flowchart illustrating a flow of processing by the resident app <NUM> installed by the application <NUM>. The present flowchart is processing executed by the resident app <NUM>. That is, the processing is implemented by the CPU <NUM> deploying and executing the program stored in the auxiliary storage device <NUM> of the PC <NUM> into the RAM <NUM>.

First, in S1001, the resident app <NUM> is activated. The resident app <NUM> is activated by the OS function after the application <NUM> performs the installation processing of the resident app <NUM> in S908 or when the PC <NUM> is activated.

In S1002, the resident app <NUM> obtains the clock time information registered by the application <NUM> from the registry in the PC <NUM>. In S1002, if the clock time information is not registered on the registry and no clock time information can be obtained, the processing proceeds to S1010. On the other hand, in S1002, if the clock time information is registered on the registry, the processing proceeds to S1003. In S1003, the resident app <NUM> confirms the elapsed time from the clock time registered on the registry. If the certain clock time (for example, <NUM> minutes) does not elapse from the clock time registered on the registry, the processing proceeds to S1010.

On the other hand, in S1003, if the certain clock time elapses from the clock time registered on the registry, the processing proceeds to S1004. In S1004, the resident app <NUM> displays the PC reboot notification pop-up <NUM> on the monitor <NUM>. In S1005, if the user presses the "reboot now" button <NUM> on the PC reboot notification pop-up <NUM>, the resident app <NUM> proceeds to S1006. On the other hand, if the user presses the "reboot later" button <NUM> or the × button at the upper right of the screen on the PC reboot notification pop-up <NUM>, the processing proceeds to S1007.

In S1006, the resident app <NUM> instructs the PC <NUM> to reboot immediately, and the processing proceeds to S1010. In S1007, the resident app <NUM> confirms the state of the "do not display notification from now" checkbox <NUM>. That is, in S1006, if the user presses the "reboot later" button <NUM> while the "do not display notification from now" checkbox <NUM> is checked, the processing proceeds to S1009 after the present step.

On the other hand, if the user presses the "reboot later" button <NUM> while the "do not display notification from now" checkbox <NUM> is not checked, the processing proceeds to S1008 after the present step. In S1008, the resident app <NUM> updates the clock time information registered on the registry to the current clock time, and the processing proceeds to S1010. In S1009, the resident app <NUM> deletes the clock time information registered on the registry, and the processing proceeds to S1010.

In S1010, the resident app <NUM> determines whether the PC <NUM> is shut down or rebooted. If the PC <NUM> is shut down or rebooted (that is, if it is determined as YES), the resident app <NUM> ends the loop processing and ends the present flow. On the other hand, if the PC <NUM> is not shut down or rebooted (that is, if it is determined as NO), the resident app <NUM> proceeds to the beginning of the loop processing (S1001). In the present embodiment, in a case where the processing proceeds from S1002, S1008, and S1009 to S1010, the determination in S1010 is NO, and the processing proceeds to S1001. On the other hand, in a case where the processing proceeds from S1006 to S1010, the determination in S1010 is YES, and the present flow ends. Note that, the resident app <NUM> may stop the resident activation with the end of the present flow.

As described above, according to the present embodiment, update installation of the device driver can be performed normally. Specifically, in a case where it is determined that the PC needs to reboot to normally perform update installation of the driver, the application <NUM> confirms whether the high-speed start-up function of the PC is in the enabled state. With this, it is possible to notify the user who does not know that the high-speed start-up function is enabled of that update installation of the driver cannot be performed by shutting down the PC. Additionally, it is possible to prevent the user himself/herself from forgetting reboot of the PC by periodically displaying the PC reboot notification pop-up <NUM> by the resident app <NUM> or the like even in a case where the user rejects immediate reboot.

Note that, in the present embodiment, an example where the "do not display notification from now" checkbox <NUM> is provided in the PC reboot notification pop-up <NUM> is described; however, it is not limited thereto. For example, a checkbox having the similar function may be provided in the PC reboot reminding message <NUM>.

Additionally, in the present embodiment, an example where the PC reboot notification pop-up <NUM> is displayed from the resident app <NUM> bundled together with the application <NUM> is described; however, it is not limited thereto. For example, a notification pop-up may be displayed from another application that is already in the PC <NUM>, or if the OS built in the PC <NUM> has a pop-up display function that allows for designation of displayed contents or display intervals, the function may be used.

Moreover, for example, in a case where update installation of the two drivers, the printer driver <NUM> and the scanner driver <NUM>, is performed, the resident app <NUM> may manage the notification of reboot related to multiple number of driver installation with a single activation.

Furthermore, although S907 and S908 are executed after S906 as the processing by the application <NUM> in the above descriptions, the processing may end without executing S907 and S908. In accordance with this, the processing by the resident app <NUM> illustrated in <FIG> may not be executed.

According to the descriptions of Embodiment <NUM>, it is possible to notify the user who does not know that the high-speed start-up function is enabled of that update installation of the driver cannot be performed by shutting down the PC. Additionally, even in a case where the user rejects immediate reboot, it is possible to prevent the user himself/herself from forgetting rebooting the PC by periodically displaying the PC reboot notification pop-up by the resident app and the like.

In the present embodiment, here is additionally assumed the following use case. That is, for example, a case where a failure of the already installed driver is minor (for example, a character in user interface (UI) texts of the driver is missing). In a case where a failure of the already installed driver is major (for example, the device itself has an error), the PC needs to be rebooted for normal installation, and therefore the method of Embodiment <NUM> is effective. However, in a case where a failure of the already installed driver is minor, there is no problem to use the device driver without normally performing update installation by rebooting the PC. Additionally, if the user is reminded of PC reboot frequently by the pop-up and the like, there is a risk that some users may be bothered.

In the present embodiment, here is described a method of switching the installation sequence or the guidance method of PC reboot in accordance with the degree of severity of the failure remaining in the already installed device driver even in a use case as described above. Note that, descriptions of a configuration duplicated with that of Embodiment <NUM> are omitted.

<FIG> is a block diagram illustrating a software configuration of the PC <NUM> communicating with the device <NUM> in the present embodiment. Trouble history information <NUM> is an external file managing information on troubles that occur in the device driver in the past. In the trouble information, the degrees of severity of the troubles (hereinafter, trouble levels), the versions in which the troubles occur, and the details of the troubles are associated with each other in stages. A trouble history information obtainment unit <NUM> obtains the trouble levels and the versions in which the troubles occur registered on the trouble history information <NUM>.

A driver version obtainment unit <NUM> obtains version information on the device driver already installed on the PC <NUM>. In this process, the target as the version information on the already installed driver to be obtained has the same device name as that registered on the driver INF file <NUM>. A countermeasure level determination unit <NUM> determines the countermeasure level of the application <NUM> based on the trouble level of the already installed driver, the version information on the already installed driver, and the state of the high-speed start-up function of the PC <NUM>.

<FIG> is a diagram illustrating an example of the trouble history information <NUM>. For example, a trouble with the details that an error occurs only during printing with a specific paper type in the version of v1. <NUM> is described as a trouble level <NUM>.

<FIG> are diagrams illustrating conditions for a case of countermeasure level determination and is a diagram illustrating details of contents of processing by the application in accordance with the countermeasure level. <FIG> is a table illustrating an example of conditions for the countermeasure level determination unit <NUM> of the application <NUM> in the present embodiment to determine the countermeasure level.

<FIG> is a table illustrating an example of contents of processing for each countermeasure level that are processed by the application <NUM> in the present embodiment. As illustrated in <FIG>, the countermeasure levels are set in stages based on the trouble levels of the already installed driver and the high-speed start-up function and are divided into three stages in the present embodiment. The application <NUM> performs processing for the trouble by executing the processing in accordance with the countermeasure level.

<FIG> is a flowchart illustrating a flow of processing from the activation to the end of the application <NUM> in the present embodiment. The present flowchart is processing executed by the functions provided in the application <NUM>. That is, the processing is implemented by the CPU <NUM> deploying and executing the program stored in the auxiliary storage device <NUM> of the PC <NUM> into the RAM <NUM>.

The present flow is started by the user activating the application <NUM>. In S1401, the application <NUM> displays the during-installation screen <NUM> and determines the countermeasure level.

Next, in S1402, the application <NUM> installs the device driver. Once the installation is completed, the application <NUM> switches the UI screen from the during-installation screen <NUM> to the installation completion screen <NUM>.

In the installation completion screen <NUM>, once the user presses the "END" button <NUM> or the × button at the upper right of the screen, the application <NUM> closes the installation completion screen <NUM> and proceeds to S1403 to execute the reboot guidance of the PC <NUM>. After S1403, the application <NUM> ends the processing in <FIG>. Note that, the countermeasure level determined in S1401 is reflected on the procedure contents during the driver installation processing and the reboot guidance processing in S1402 and S1403. Detailed processing flows of the countermeasure level determination processing, the driver installation processing, and the reboot guidance processing in <FIG> are described, respectively.

<FIG> is a flowchart illustrating a detailed flow of the countermeasure level determination processing (S1401) in <FIG>.

First, in S1501, the application <NUM> determines whether the device driver as the installation target is already installed on the PC <NUM>. If the device driver is not installed yet, the application <NUM> ends the processing in <FIG>. On the other hand, if the device driver is already installed, the processing proceeds to S1502.

In S1502, the trouble history information obtainment unit <NUM> obtains the trouble information from the trouble history information <NUM>. In S1503, the driver version obtainment unit <NUM> obtains the version information from the already installed driver that is installed on the PC <NUM>.

Next, in S1504, S1505, and S1506, the countermeasure level determination unit <NUM> determines the trouble level in a case where the version of the already installed driver matches the version information included in the trouble information. In S1504, if it is determined that the trouble level is <NUM> based on the version of the already installed driver, the countermeasure level determination unit <NUM> sets the countermeasure level to <NUM> in S1507 and ends the present flow. If it is determined that the trouble level is not <NUM> in S1504, the processing proceeds to S1505. In S1505, the countermeasure level determination unit <NUM> determines whether the trouble level is <NUM>. If it is determined that the trouble level is <NUM>, the processing proceeds to S1508. On the other hand, if it is determined that the trouble level is not <NUM>, the processing proceeds to S1506. In S1508, the countermeasure level determination unit <NUM> determines whether the high-speed start-up function of the PC <NUM> is in the enabled state or the disabled state. In S1508, if the high-speed start-up function is in the enabled state, the countermeasure level determination unit <NUM> sets the countermeasure level to <NUM> and ends the processing in <FIG>. On the other hand, if the high-speed start-up function is in the disabled state in S1508, the countermeasure level determination unit <NUM> sets the countermeasure level to <NUM> and ends the present flow.

Additionally, in S1506, if it is determined that the trouble level is <NUM>, the processing proceeds to S1510, the countermeasure level determination unit <NUM> sets the countermeasure level to <NUM> and ends the present flow. On the other hand, if it is determined that the version of the already installed driver does not match any of the versions of the trouble levels included in the trouble information (if it is determined as NO in S1506), the countermeasure level determination unit <NUM> ends the present flow.

<FIG> is a flowchart illustrating a detailed processing flow of the driver installation processing (S1402) in <FIG>. First, in S1601, the driver installation unit <NUM> determines whether the result of the countermeasure level determination processing S1401 is the countermeasure level <NUM>. If it is determined that it is other than the countermeasure level <NUM>, the processing proceeds to S1602, and if it is determined that it is the countermeasure level <NUM>, the processing proceeds to S1603. Note that, the countermeasure level used in the present step is the countermeasure level that is determined by the countermeasure level determination unit <NUM> in S1401 and obtained by the driver installation unit <NUM>.

In S1602, the driver installation unit <NUM> installs each type of the drivers (the printer driver <NUM>, the scanner driver <NUM>, or the fax driver <NUM>) bundled together with the application <NUM>. Thereafter, the present flow ends.

On the other hand, if it is determined as YES in S1601, the processing proceeds to S1603, and the driver installation unit <NUM> uninstalls the already installed driver. In S1604, the application <NUM> reboots a print spooler. This is for avoiding a situation where the update installation cannot be normally applied unless rebooting the PC <NUM> because the driver module already installed on the PC <NUM> holds the print spooler. After S1604, in S1602, the driver installation unit <NUM> installs each type of the drivers bundled together with the application <NUM>. Thereafter, the present flow ends.

<FIG> is a flowchart illustrating a detailed processing flow of the reboot guidance processing (S1403) in <FIG>.

First, in S1701, as with the processing in S901 in <FIG>, the reboot determination unit <NUM> determines the necessity of rebooting the PC <NUM> for update installation of the driver as a result of the driver installation in the driver installation processing S1402. If it is determined that reboot of the PC is unnecessary, the reboot determination unit <NUM> ends the present flow. On the other hand, if it is determined that reboot of the PC <NUM> is necessary, the reboot determination unit <NUM> proceeds to S1702.

In S1702, the reboot determination unit <NUM> displays the PC reboot selection message <NUM> on the monitor <NUM> of the PC <NUM>. In S1703, if the user presses the "YES" button <NUM> of the PC reboot selection message <NUM>, the processing proceeds to S1704, and the reboot determination unit <NUM> executes immediate reboot of the PC <NUM>. Thereafter, the reboot determination unit <NUM> ends the present flow. On the other hand, in S1703, if the user presses the "NO" button <NUM> or the × button at the upper right of the screen of the PC reboot selection message <NUM>, the processing proceeds to S1705.

In S1705, the reboot determination unit <NUM> determines whether the countermeasure level set in the countermeasure level determination processing S1401 is <NUM>. If the countermeasure level is other than <NUM> (if it is determined as NO in S1705), the reboot determination unit <NUM> ends the present flow. On the other hand, if the countermeasure level is <NUM> (if it is determined as YES in S1705), the processing proceeds to S1706.

In S1706, the reboot determination unit <NUM> displays the PC reboot reminding message <NUM> on the monitor <NUM>. If the user presses the "OK" button <NUM> or the × button at the upper right of the screen in the PC reboot reminding message <NUM>, the reboot determination unit <NUM> closes the PC reboot reminding message <NUM>.

In S1707, the reboot determination unit <NUM> registers the current clock time information on the registry in the PC <NUM> for the resident app <NUM> to periodically display the PC reboot notification pop-up <NUM>. After S1707, the reboot determination unit <NUM> installs the resident app <NUM>. The processing by the resident app <NUM> is similar to that in <FIG>. After S1708, the reboot determination unit <NUM> ends the present flow.

As described above, according to the present embodiment, the application <NUM> changes the installation sequence or the method of guiding reboot of the PC <NUM> for the user in accordance to the countermeasure level. With such a configuration, it is possible to prevent the user from facing the failure of the already installed driver as much as possible even in a case where the failure remains in the old device driver already installed on the PC <NUM>. Additionally, in the present embodiment, comparing with the Embodiment <NUM>, it is possible to minimize the opportunity that the user is notified again by the message box or the pop-up.

Moreover, according to the present embodiment, it is described that, as the contents of processing of the countermeasure level <NUM>, the application <NUM> executes uninstallation of the already installed driver and reboot of the print spooler. However, on the other hand, depending on the specification of the PC <NUM>, there is a risk that the display time of the during-installation screen <NUM> may be longer than a case of new installation or update installation. To deal with this, the application <NUM> may guide the PC reboot under the operating specification of the OS without rebooting the spooler. Furthermore, in a case where the module as the target of the update installation is other than the driver module held by the print spooler, the application <NUM> may skip the uninstallation of the already installed driver S1603 and the spooler reboot S1604.

Note that, in the present embodiment, an example where the trouble levels in <FIG> or the countermeasure levels in <FIG> have three stages; however, it is not limited thereto. For example, the stages of the trouble levels and the countermeasure levels may be increased or decreased. Additionally, the trouble levels and the countermeasure levels may not be divided into the same number of stages.

Additionally, in the present embodiment, an example where the countermeasure levels and the contents of processing by the application <NUM> are associated with each other as illustrated in <FIG> is described; however, it is not limited thereto. For example, the contents of processing of the countermeasure level <NUM> and the countermeasure level <NUM> may be exchanged or may be changed into different processing contents.

Moreover, in the present embodiment, an example where the trouble history information <NUM> is bundled in the same package as the application <NUM> is described; however, it is not limited thereto. For example, the trouble history information <NUM> may be managed on a Web server, the application <NUM> may access the server through a network, and the contents may be referred to or automatically downloaded to obtain the information.

In the above-described embodiments, the processing in a case of update installation of the driver is described; however, it is not limited thereto. For example, the above-described embodiments may be applied to a case of update installation of general software in the PC provided with the high-speed start-up function. Additionally, the above-described embodiments are effective not only for update installation but also in a case of installing new software.

Claim 1:
A control method of an information processing apparatus (<NUM>), comprising:
installing a predetermined program(S801); and
executing (S802) a predetermined notification to notify and prompt a user to reboot the information processing apparatus based on a case where a predetermined function is enabled in the information processing apparatus, the predetermined function being related to processing for a case where a shutdown operation of the information processing apparatus is performed,
wherein
the predetermined function is a function of setting the information processing apparatus to hibernation instead of completely shutting down the information processing apparatus in a case where the shutdown operation of the information processing apparatus is performed, and
the information processing apparatus is completely shut down in a case where the shutdown operation of the information processing apparatus is performed while the predetermined function is not enabled;
characterized in that
the execution executes the predetermined notification upon completion of processing performed by the installing; and
in a case where the predetermined function is enabled (S905:YES), the executing executes the predetermined notification (<NUM>) to notify (S906) the user that a reboot of the information processing apparatus is required to apply updated contents as a result of said installation, and that said updated contents will not be applied if the shutdown operation is performed.