Information processing apparatus and computer readable storage medium

According to one embodiment, an information processing apparatus includes a processor, a volatile memory, a BIOS-ROM, and an interface. An embedded OS in the BIOS-ROM causes the processor to execute connecting the apparatus to a server via a network, and when the server sets a first OS as an OS in the apparatus by switching from the embedded OS, and a nonvolatile memory connected via the interface stores a second OS used at previous startup of the apparatus, loading the second OS into the volatile memory and starting the second OS. The second OS causes the processor to execute downloading the first OS from the server and storing the downloaded first OS in the nonvolatile memory.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based upon and claims the benefit of priority from Japanese Patent Application No. 2017-091308, filed May 1, 2017, the entire contents of which are incorporated herein by reference.

FIELD

Embodiments described herein relate generally to a technology for desktop virtualization.

BACKGROUND

In recent years, information has been frequently leaked by losses or thefts of personal computers (i.e. client terminals).

Thus, companies carrying out business, such as infrastructure business or medical business, are required to strictly manage their confidential information. So they are introducing such client terminals communicating with a server that can provide virtual desktop environment.

For example, a client terminal holds a basic input/output system (BIOS) and an operating system (OS) as minimum requirements. When booting up them, the client terminal is able to communicate with a server via a network and a client software for realizing virtual desktop environment on the client terminal is downloaded from the server.

Thus, as the client software is downloaded to the client terminal from the server during startup, the startup time tends to become long until the time when the user can use the virtual desktop environment.

DETAILED DESCRIPTION

In general, according to one embodiment, an information processing apparatus includes a processor, a volatile memory, a BIOS-ROM, and an interface. The BIOS-ROM is configured to store a basic input/output system (BIOS) and an embedded operating system. A removable and nonvolatile memory is connectable to the interface. The embedded operating system is configured to cause the processor to execute: connecting the information processing apparatus to a server via a network; and when the server sets a first operating system as an operating system in the information processing apparatus by switching from the embedded operating system, and the nonvolatile memory connected via the interface stores a second operating system used at previous startup of the information processing apparatus, loading the second operating system into the volatile memory and starting the second operating system. The second operating system is configured to cause the processor to execute: downloading the first operating system from the server; and storing the downloaded first operating system in the nonvolatile memory.

With reference toFIG. 1, this specification explains a system including an information processing apparatus according to one embodiment. The information processing apparatus functions as a client terminal for communicating with a server configured to provide virtual desktop environment. The information processing apparatus may be a clamshell type apparatus similar to a notebook computer or a slate type apparatus similar to a tablet computer. In the following description, this specification exemplifies a case where a notebook client terminal1realizes the information processing apparatus.

The client terminal1can communicate with a management server2via a network such as a wireless LAN or wired LAN. The client terminal1can also communicate with, via a network, a VDI server4configured to provide multiple client terminals including the client terminal1with virtual desktop environment.

The management server2has a function for confirming whether each client terminal is an authorized client terminal, and providing each client terminal1confirmed as an authorized client terminal with a program and information necessary for communication with the VDI server4. Thus, the management server2functions as a client authentication site and a download site.

The VDI server4can use some types of technologies to realize desktop virtualization for providing virtual desktop environment. One of the technologies is virtual desktop infrastructure (VDI).

In the present embodiment, the system may use VDI as a technology to realize desktop virtualization. In this case, the VDI server4functions as a server configured to provide virtual desktop environment using VDI. The client terminal1functions as a VDI client terminal. The VDI server4transmits the image data (VDI screen data) of a screen and image data corresponding to the update portion of the screen to the client terminal1to provide virtual desktop environment. When the client terminal1displays a screen based on the image data, a user of the client terminal1can use desktop environment that is generated by a virtual machine executed on the VDI server4as if it is desktop environment generated by the operation of the client terminal1.

An administrator console3may set a client policy used by the management server2and a VDI policy used by the VDI server4. The management server2has a function for providing the administrator console3with a web-based graphical user interface (GUI) for changing and applying the setting of the client policy. The client policy includes information indicating the OS module to be applied to a client terminal1(hereinafter, referred to as an application OS module), information indicating the possibility of a storage cache of the application OS module by the client terminal1, etc. The OS module may be the OS itself or a file (or files) in which the OS is compressed. The OS is, for example, an OS based on Linux (registered trademark).

The VDI server4has a function for providing the administrator console3with a web-based GUI for changing and applying the setting of the VDI policy. The VDI policy includes information related to the setting of the connected virtual machine (VM), information related to the setting of connection performance, etc.

FIG. 2shows an example of a policy setting screen8displayed by the administrator console3. The policy setting screen8is used for setting the policy to be applied to a client terminal1. The policy setting screen8is realized as, for example, a web-based user interface. The administrator of the management server2can determine the policy to be applied to the client terminal1by the operation on the policy setting screen8. The management server2stores policy information21indicating the determined policy and uses the policy information21to control the client terminal.

The policy setting screen8for setting the policy to be applied to a client terminal1includes items such as a policy name81, an authentication server82, an OS module83, a VDI server84, communication setting85, and a download server86. For example, each item displays the content in process of setting up. The administrator can arbitrarily change the content of each item.

The policy name81indicates the name given to the policy. The authentication server82indicates the address (URL) of the authentication server used to authenticate the client terminal1. The address indicates, for example, the connection destination for using the authentication function of the management server2.

The OS module83includes the name (file name)830of the OS module to be used and check boxes831and832. For example, after the file of a new OS module that includes a newly added function or security update is released, the administrator can set (select) the name of the released OS module as the name830of the OS module to be used.

The check box831indicates whether saving the OS module in the client terminal1is permitted. When the check box831is checked, a nonvolatile memory (external storage) connected to the client terminal1, such as a memory card can save the OS module. For example, if the client terminal1downloads the OS module via a network of poor quality at the time of startup (boot-up), the downloading requires a large amount of time. Thus, it takes long to complete the startup. When the check box831is checked, the external storage connected to the client terminal1caches the OS module. The client terminal1loads the OS module from the external storage at the next startup. Since the client terminal1skips downloading the OS module at the next start up, the client terminal1can boot up rapidly.

The check box832indicates whether downloading the OS module in the background is permitted when saving the OS module in the client terminal1is permitted. As shown inFIG. 2, the check box832may be operable by the administrator when the check box831is checked, in other words, when saving the OS module in the client terminal1is permitted. The check box832may not be operable by the administrator when the check box831is unchecked, in other words, when saving the OS module in the client terminal1is prohibited.

The VDI server84indicates the address of the VDI server4. The communication setting85indicates the operation setting of the client terminal1. The communication setting85includes, for example, the number of and interval of communication retries, the polling interval of startup authentication, and an action at the time of communication disconnection. The download server86indicates the address of the download server. The address of the download server indicates, for example, the connection destination for using the download function of the management server2. The management server2functions as an authentication server for the access to the address indicated in the authentication server82, and functions as a download server for the access to the address indicated in the download server86.

The client terminal1does not have built-in storage (for example, a hard disk drive [HDD] or solid-state drive [SSD]), and for example, downloads the OS module (file) of an operating system including a program necessary for communication with the VDI server4from the management server2via a network at the time of startup. The client terminal1places (loads) the downloaded OS module on the volatile memory and executes the placed OS module to communicate with the VDI server4.

This OS module may be stored (cached) in external storage connected to the client terminal1, such as an SD card or USB flash memory. The client terminal1can reduce the time required to complete startup (for example, the time until the client terminal1can communicate with the VDI server4) since the client terminal1places the stored OS module from the external storage on a volatile memory and executes the OS module at the time of startup.

The management server2sets the OS module to be used in each client terminal1and changes it in accordance with the addition of a new function, security update, etc. For example, when the management server2changes the OS module to be used in a client terminal1, the client terminal1downloads a new OS module from the management server2and stores it in external storage at the time of booting the client terminal1. The client terminal1then places the downloaded OS module on a volatile memory and executes it. Thus, the storage time in the external storage may increase the startup time of the client terminal1in comparison with a case where the client terminal1simply downloads a new OS module from the management server2.

In the present embodiment, a client terminal1is booted using an OS module already stored in external storage in a case where the client terminal1finds that the management server2changes the OS module to be used in the client terminal1, at the time of startup. After the startup, the client terminal1downloads the changed OS module from the management server2in the background and newly stores the OS module in external storage. In this way, even when the management server2changes the OS module to be used in the client terminal1, the startup time can be reduced by using the OS module already stored in external storage. In addition, the client terminal1can use the OS module newly stored in external storage at the next startup or afterward without downloading the changed OS module from the management server2at the time of startup. In this manner, the client terminal1can reduce the startup time.

With reference toFIG. 3, this specification explains the functional configuration of the client terminal1of the present embodiment. Here, this specification shows an example in which a removably connectable nonvolatile memory, such as a memory card19A, is connected to the client terminal1.

The management server2includes a storage device that stores the policy information21, an OS module22, etc. The OS module22includes VDI connection software. The VDI connection software is a client program (VDI client program) configured to communicate with the VDI server4providing virtual desktop environment and receive a virtual desktop image from the server.

When the VDI server4is realized as a virtual machine type, multiple virtual machines41are executed on the VDI server4. The VDI server4allocates one of the virtual machines41to the client terminal1. Each virtual machine41includes a virtual OS (client desktop OS)43and an application program42executed on the virtual OS43. It should be noted that the VDI server4is not limited to a virtual machine type. The VDI server4may be realized as a blade computer type, a terminal type, etc.

When a power button is pressed, the client terminal1executes a basic input/output system (BIOS)141stored in a BIOS-ROM14to start an embedded OS142. The embedded OS142is, for example, Small Linux, and includes instructions minimum required such as instructions for network connection and downloading the application OS module from the management server2. The management server2sets the application OS module to cause the client terminal1to use it. When the client terminal1executes the embedded OS142, the client terminal1is connected to a wired or wireless network. The BIOS may be a UEFI BIOS. A flash EEPROM may constitute the BIOS-ROM14to enable update.

The embedded OS142connects the client terminal1to the management server2via a network. When the management server2sets a first OS as the OS to be used in the client terminal1by switching from the embedded OS142, and the memory card19A is connected via an interface such as a card slot and stores not the first OS but a second OS that is used at the previous startup of the client terminal1, the embedded OS142, when executed, causes various components provided in the client terminal1, such as a processor (CPU), to execute functions of loading the second OS into a RAM (main memory)13and starting the second OS. More specifically, the instructions included in the embedded OS142controls, when executed, various components provided in the client terminal1, such as the processor (CPU), so as to function (operate) as a connection control module51, a module determination module52, a first download control module53, and a startup control module54.

The connection control module51connects the client terminal1with the management server2via a wired or wireless network. The connection control module51performs a process for authenticating the client terminal1with the management server2.

When the management server2authenticates the client terminal1at the time of startup of the client terminal1, the module determination module52receives first information and second information from the management server2. The first information specifies the application OS module to be used in the client terminal1(for example, a file name of the application OS module). The second information indicates whether saving the application OS module in the client terminal1is permitted. The first and second information are included in the policy information21of the management server2. When saving the application OS module in the client terminal1is permitted, the second information may further include information indicating whether downloading the application OS module in the background is permitted.

The module determination module52uses the first information and the previously used module information143stored in the BIOS-ROM14to determine whether the application OS module that is set by the management server2and should be used in the client terminal1is changed from the OS module stored (cached) in the memory card19A. The module determination module52uses the previously used module information143(for example, a file name of the previously used OS module) to specify the previously used OS module.

The module determination module52determines that the application OS module to be used in the client terminal1is not changed from the previously used OS module when the first information and the previously used module information143indicate the same OS module. The module determination module52determines that the application OS module to be used in the client terminal1is changed from the previously used OS module when the first information indicates an OS module different from that of the previously used module information143. When the application OS module is changed from the previously used OS module, the module determination module52updates (overwrites) the previously used module information143with the first information specifying the application OS module.

Subsequently, the module determination module52uses the second information to determine whether saving the application OS module to be used in the client terminal1in the client terminal1is permitted, in other words, whether storing the application OS module in external storage (for example, the memory card19A) is permitted.

When saving the application OS module in the client terminal1is prohibited, the client terminal1can obtain the application OS module only by the download from the management server2. Thus, the first download control module53downloads the application OS module from the management server2and places it as a non-embedded OS131on the RAM13. The startup control module54starts the non-embedded OS131placed on the RAM13. The startup control module54switches the control such that the driver and library included in the non-embedded OS131are executed while succeeding to the setting of the embedded OS142.

When saving the application OS module in the client terminal1is permitted, the module determination module52, the first download control module53and the startup control module54perform the following operation.

When the memory card19A does not store the application OS module, the module determination module52operates based on whether downloading the application OS module in the background is permitted, using the second information.

In other words, when the memory card19A does not store the application OS module, and saving the application OS module in the client terminal1is permitted and downloading it in the background is prohibited, the first download control module53downloads the application OS module from the management server2and places it as the non-embedded OS131on the RAM13. The first download control module53then stores the downloaded application OS module in the memory card19A. In this way, when downloading an application OS module in the background is prohibited, the application OS module is always downloaded and stored in the memory card19A at the time of startup. Thus, when the administrator does not want the user to use the OS module used at the previous startup of the client terminal1in consideration of the security and function update, the use of the OS module can be prevented.

When the memory card19A does not store the application OS module and stores the OS module191used at the previous startup of the client terminal1, and saving the application OS module in the client terminal1and downloading it in the background are permitted, the module determination module52places the OS module191as the non-embedded OS131on the RAM13from the memory card19A.

When the memory card19A stores neither the application OS module nor the OS module used at the previous startup of the client terminal1, and saving the application OS module in the client terminal1and downloading it in the background are permitted, the first download control module53downloads the application OS module from the management server2and places it as the non-embedded OS131on the RAM13. The first download control module53then stores the downloaded application OS module in the memory card19A.

When, on the policy setting screen8shown inFIG. 2, the administrator prohibits saving the application OS module in the client terminal1, or the administrator permits saving the application OS module in the client terminal1and prohibits downloading the application OS module in the background, using the OS module used at the previous startup of the client terminal1to start the non-embedded OS131can be prohibited. When, on the policy setting screen8shown inFIG. 2, the administrator permits saving the application OS module in the client terminal1and downloading the application OS module in the background, using the OS module used at the previous startup of the client terminal1to start the non-embedded OS131can be permitted.

In this way, the startup control module54starts the non-embedded OS131placed on the RAM13. The startup control module54switches the control such that the driver and library included in the non-embedded OS131are executed while succeeding to the setting of the embedded OS142.

The instructions included in the non-embedded OS131controls, when executed, various components provided in the client terminal1, such as the processor (CPU), so as to function (operate) as a VDI client processing module61, a second download control module62and a notification processing module63.

The VDI client processing module61connects the client terminal1with a virtual machine41on the VDI server4via a network. The VDI client processing module61receives the image data of the screen (VDI screen data) for virtual desktop environment and image data corresponding to the update portion of the screen from the VDI server4. The VDI client processing module61displays a screen based on the image data. The VDI client processing module61can transmit the operation information of an input device by the user to the VDI server4via a network. The operation information of an input device includes, for example, the operation information of a keyboard (software keyboard), the operation information of a mouse, and touch operation information for a touchpad, a touchscreen display, etc.

When the non-embedded OS131starts by using the OS module191used at the previous startup of the client terminal1(for example, the OS module stored in the memory card19A), the second download control module62downloads the application OS module from the management server2. The second download control module62then stores (caches) the downloaded application OS module in the memory card19A. In a case where the non-embedded OS131starts by using the OS module191used at the previous startup of the client terminal1, saving the application OS module in the client terminal1(here, the memory card19A) is permitted. Thus, when the management server2permits storing (saving) the application OS module in the memory card19A, the second download control module62downloads the application OS module from the management server2and stores the downloaded application OS module in the memory card19A. When the management server2prohibits storing the application OS module in the memory card19A, the second download control module62does not download the application OS module from the management server2. Since the second download control module62is configured to operate parallel to the VDI client processing module61providing virtual desktop environment, the second download control module62can download the application OS module in the background.

When downloading the application OS module and storing it in the memory card19A are completed, the notification processing module63may notify the user that a new application OS module is cached and prompt the user to reboot the client terminal1. For example, the notification processing module63displays a message indicating that a new application OS module is cached on the screen.

When the user performs operation for shutting down the client terminal1while the second download control module62downloads and stores (caches) the application OS module, the notification processing module63may notify the user that the download and storage of the application OS module are in progress. Then, the notification processing module63may make the user select either immediate shutdown of the client terminal1or shutdown of the client terminal1after the completion of the download and storage. For example, the notification processing module63displays, on the screen, a dialogue including a message indicating that the download and storage of the application OS module are in progress, a button for selecting immediate shutdown, and a button for selecting shutdown after the completion of download and storage. When the user selects immediate shutdown, the second download control module62may resume downloading and storing the application OS module in the background at the next time the client terminal1is booted.

The instructions included in the non-embedded OS131may control, when executed, various components provided in the client terminal1, such as the processor (CPU), so as to further function (operate) as a module determination module64.

The module determination module52of the embedded OS142described above determines, at the time of startup, whether the management server2changes the OS to be used in the client terminal1by switching from the embedded OS142from the previously used OS module to a different OS module. In this way, the module determination module52is configured to detect the change in the application OS module only at the time of booting the client terminal1.

The module determination module64of the non-embedded OS131regularly confirms the change in the application OS module by the management server2after the startup of the non-embedded OS131. Thus, for example, the module determination module64can detect the change in the application OS module by the management server2while the VDI client processing module61communicates with the VDI server4to provide virtual desktop environment to the client terminal1.

When the module determination module64detects the change in the application OS module and the memory card19A does not store (cache) the application OS module, the second download control module62downloads a new application OS module from the management server2in the background and stores the downloaded application OS module in the memory card19A. Thus, there is a high possibility that the latest application OS module is stored in the memory card19A at the next time the client terminal1is booted. In this way, it is possible to increase the probability that the client terminal1uses the intended OS module for the administrator.

Further, the module determination module64may detect a further change in the application OS module by the management server2while the second download control module62downloads the application OS module from the management server2. In this case, the second download control module62stops downloading the application OS module and starts downloading the new application OS module set by the management server2and storing it in the memory card19A. In this way, it is possible to prevent the decrease in free space caused by caching useless data such as an unnecessary OS module in the memory card19A.

With reference to the flowchart ofFIG. 4, this specification explains an example of the procedure of a startup control process executed by a client terminal1. Here, this specification shows an example in which the client terminal1does not include the second download control module62configured to download the OS module22in the background.

When the client terminal1is booted, the embedded OS142is started (step S101). The OS module (application OS module) that should be applied to the client terminal1and is set in the management server2is confirmed by communication with the management server2(step S102).

Subsequently, whether the cache of the application OS module in external storage (here, the memory card19A) is permitted is determined (step S103). When the cache in external storage is not permitted (No in step S103), the application OS module is downloaded from the management server2to the client terminal1(step S104).

When the cache in external storage is permitted (Yes in step S103), whether the application OS module is already cached in external storage is determined (step S105). When the application OS module is already cached in external storage (Yes in step S105), the cached application OS module is loaded from the external storage (step S106).

When the application OS module is not cached (No in step S105), the application OS module is downloaded from the management server2(step S107) and is cached in external storage (step S108).

Subsequently, the application OS module loaded from the external storage in step S106is, or the application OS module downloaded from the management server2in step S104or step S107is decoded and is placed as the non-embedded OS131on the main memory13(step S109). The control is switched from the embedded OS142to the non-embedded OS131by dynamically switching the OS (step S110), and the startup is completed.

In the above startup control process, the control can be switched from the embedded OS142to the non-embedded OS131, using the application OS module cached in the memory card19A or the application OS module downloaded from the management server2. In this startup control process, when the application OS module is downloaded from the management server2, a process for the cache in the memory card19A is performed in addition to download. Thus, the startup time is equal to or longer than that of normal startup which does not use the memory card19A (external storage).

Thus, the client terminal1of the present embodiment is configured to provisionally start the non-embedded OS131with the OS module used at the previous startup and download a new application OS module in the background. The flowchart ofFIG. 5shows an example of the procedure of a startup control process executed by each client terminal1. For example, this startup control process is realized when the CPU11of the client terminal1executes the instructions included in the embedded OS142and the instructions included in the non-embedded OS131.

When the client terminal1is booted, the embedded OS142is started (step S201). The OS module (application OS module) that is set in the management server2and should be applied to the client terminal1is confirmed by communication with the management server2(step S202). By this confirmation, for example, information by which the application OS module can be specified (for example, a file name or ID) is obtained.

Subsequently, whether the confirmed application OS module is different from the previously used OS module is determined (step S203). The information143(for example, a file name or ID) related to the previously used OS module is stored in, for example, the BIOS-ROM14. It is possible to determine whether the confirmed application OS module is different from the previously used OS module by using the information143.

When the confirmed application OS module is different from the previously used OS module (Yes in step S203), the information (for example, a file name or ID) by which the application OS module can be specified is stored in, for example, the BIOS-ROM14, as the information143related to the previously used OS module. When the confirmed application OS module is the same as the previously used OS module (No in step S203), the process of step S204is skipped.

Subsequently, whether the cache of the application OS module in external storage (here, the memory card19A) is permitted is determined (step S205). When the cache in external storage is not permitted (No in step S205), the application OS module is downloaded from the management server2to the client terminal1(step S206).

When the cache in external storage is permitted (Yes in step S205), whether the application OS module is already cached in external storage is determined (step S207). When the application OS module is already cached in external storage (Yes in step S207), the cached application OS module is loaded from the external storage (step S208).

When the application OS module is not cached (No in step S207), whether the previously used OS module is already cached in external storage is determined (step S209). When the previously used OS module is already cached in external storage (Yes in step S209), the cached previously used OS module is loaded from the external storage (step S210).

When the previously used OS module is not cached in external storage (No in step S209), the application OS module is downloaded from the management server2(step S211), and is cached in external storage (step S212). For example, the application OS module is stored in external storage after encryption with a key unique to the device (for example, the client terminal1).

Subsequently, the application OS module obtained in step S206, step S208or step S211is, or the previously used OS module obtained in step S210is, decoded, and is placed on the main memory13as the non-embedded OS131(step S213). By dynamically switching the OS, the control is switched from the embedded OS142to the non-embedded OS131(step S214). On the client terminal1, for example, the control is switched by executing the driver and library included in the non-embedded OS131while succeeding to the setting of the embedded OS142.

Whether starting the non-embedded OS131after switching uses the previously used OS module is determined (step S215). When starting the non-embedded OS131uses the previously used OS module (Yes in step S215), downloading the application OS module confirmed in step S202is started in the background (step S216). When starting the non-embedded OS131does not use the previously used OS module (No in step S215), in other words, when starting the non-embedded OS131uses the application OS module confirmed in step S202, the process of step S216is skipped.

In the above manner, when starting the non-embedded OS131uses the previously used OS module, downloading the application OS module is started in the background. Thus, it is possible to quickly activate the client terminal1by avoiding the increase in the time required to complete the startup of the client terminal1because of downloading the application OS module.

With reference to the flowchart ofFIG. 6, this specification explains an example of the procedure of a download control process executed by each client terminal1. For example, this download control process is executed after the completion of the startup of the client terminal1by the startup control process shown inFIG. 5.

The application OS module that is set in the management server2and should be applied to the client terminal1is confirmed by the communication with the management server2(step S31). Whether the application OS module is changed after the previous confirmation is determined based on the above confirmation (step S32). When the application OS module is not changed (No in step S32), the process returns to step S31.

When the application OS module is changed (Yes in step S32), whether the application OS module is already cached in external storage (here, the memory card19A) is determined (step S33). When the application OS module is already cached in the external storage (Yes in step S33), the process returns to step S31.

When the application OS module is not cached in external storage (No in step S33), whether downloading an OS module different from the application OS module is in progress in the background is determined (step S34). When downloading an OS module different from the application OS module is in progress in the background (Yes in step S34), downloading the OS module is stopped (step S35). When downloading an OS module different from the application OS module is not in progress in the background (No in step S34), the process of step S35is skipped. Subsequently, downloading a new application module, in other words, the application OS module currently set for the client terminal1in the management server2, is started in the background (step S36). The process then returns to step S31.

As described above, when the management server2changes the setting of the OS module to be applied to the client terminal1after the startup of the client terminal1, the client terminal1can download, in place of the OS module before change, the OS module after change in the background and can cache it in external storage (memory card19A).

FIG. 7shows an example of the system configuration of each client terminal1.

Each client terminal1includes, in addition to the above RAM (main memory)13and the BIOS-ROM14, the CPU11, a system controller12, an LCD15, a speaker16, a communication device17, an embedded controller (EC)18, a card slot19, etc. The card slot19is an interface removably connecting the memory card19A.

The CPU11is a processor configured to execute the embedded OS142and the BIOS141stored in the BIOS-ROM14, various programs (for example, the non-embedded OS131) downloaded into the RAM (main memory)13, and various programs loaded from the memory card19A connected via the card slot19into the RAM (main memory)13.

The system controller12is a bridge device connecting the CPU11and each component. The system controller12performs data writing and reading relative to the memory card19A inserted into the card slot19, such as an SD card.

The system controller12includes a display controller configured to control the LCD15used as the display monitor of the client terminal1. The display controller generates a display signal and transmits it to the LCD15. The LCD15displays a screen image based on the display signal. The system controller12also includes an audio controller configured to control the speaker16. The audio controller generates an audio signal and transmits it to the speaker16. The speaker16outputs sound based on the audio signal.

The communication device17is configured to perform wired communication or wireless communication. The communication device17includes a transmitter configured to transmit signals and a receiver configured to receive signals. The EC18functions as a power controller configured to manage the power for turning on or off the client terminal1.

In addition to, or in place of, the card slot19, an USB connector may be provided in the client terminal1. In this case, the CPU11may execute a program loaded from, instead of the memory card19A connected via the card slot19, any nonvolatile memory connected via the USB connector, such as a flash memory, into the RAM (main memory)13.

As explained above, in the present embodiment, the startup time can be reduced. The BIOS-ROM14stores the BIOS141and the embedded OS142. The card slot19is configured to removably connect the memory card19A. The embedded OS142causes the CPU11to execute connecting the client terminal1to the management server2via a network. When the management server2sets the first OS as the OS (non-embedded OS) to be used in the client terminal1by switching from the embedded OS142, and the memory card19A connected via the card slot19A stores not the first OS (OS module) but the second OS (OS module) used at the previous startup of the client terminal1, the embedded OS142causes the CPU11to execute loading the second OS stored in the memory card19A into the RAM13and starting the second OS. The second OS causes the CPU11to execute downloading the first OS (OS module) from the management server2and storing the downloaded first OS in the memory card19A.

When the first OS to be used in the client terminal1by switching from the embedded OS is not stored in the memory card19A, the second OS already stored in the memory card19A is started. While the second OS operates, the first OS is downloaded. Thus, this startup time of the client terminal1is reduced by starting the second OS. Further, the next startup time of the client terminal1can be reduced by starting the downloaded first OS.

Each of the functions described in the present embodiment may be realized by a circuit (processing circuit). For example, the processing circuit includes a programmed processor such as a central processing unit (CPU). The processor performs each of the described functions by executing a computer program (instructions) stored in a memory. The processor may be a microprocessor including an electric circuit. For example, the processing circuit includes a digital signal processor (DSP), an application specific integrated circuit (ASIC), a microcontroller, a controller, and other electric circuit components. A processing circuit may realize each of the components other than the CPU described in the present embodiment.

A computer program can realize each process of the present embodiment. Therefore, an effect similar to that of the present embodiment can be easily realized by merely installing the computer program on a computer through a computer-readable storage medium in which the computer program is stored and executing the computer program.