Control system, electronic device, and control method

According to one embodiment, a control system includes a client terminal, a first server and a second server. The client terminal transmits an assignment request of an IP address including first identification information that uniquely identifies the client terminal and is set as a host name to the first server. The first server assigns an IP address to the client terminal in accordance with the request, and transmits the IP address and the host name to the second server. The second server transmits, when one or more items of second identification information include the first identification information set as the host name and when a setup process of the client terminal has not been performed, data for the process of the client terminal to the client terminal using the IP address.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based upon and claims the benefit of priority from Japanese Patent Applications No. 2018-107868, filed Jun. 5, 2018; and No. 2018-143730, filed Jul. 31, 2018, the entire contents of all of which are incorporated herein by reference.

FIELD

Embodiments described herein relate generally to a control system, an electronic device, and a control method.

BACKGROUND

In recent years, the number of data leakage incidents is increasing because client terminals such as a personal computer are lost and stolen. Thus, thin client terminals that communicate with servers providing virtual desktop environments are now introduced into infrastructure corporations, hospitals, and the like where strict data management is required.

Each thin client terminal may download data used for setup (initial setting) from a server. In that case, for example, a URL of the server, a file name of a file to be downloaded, and the like are set to the thin client terminals beforehand.

However, in this method, setting is required for each thin client terminal, and thus, a great workload is required in a system including many thin client terminals.

DETAILED DESCRIPTION

In general, according to one embodiment, a control system includes a first client terminal, a first server, and a second server. The first client terminal transmits an assignment request of an Internet Protocol (IP) address to the first server. The assignment request includes first identification information that uniquely identifies the first client terminal and is set as a first host name. The first server assigns a first IP address to the first client terminal in accordance with the assignment request, and transmits the first IP address and the first host name to the second server. The second server stores one or more items of second identification information that uniquely identify one or more client terminals respectively, in a memory. Each of the one or more client terminals is subject to a setup process. The second server receives the first IP address and the first host name from the first server. The second server transmits, when the one or more items of the second identification information include the first identification information set as the first host name and when the setup process of the first client terminal has not been performed, data for the setup process of the first client terminal to the first client terminal using the first IP address.

First Embodiment

A control system of a first embodiment will be explained with reference toFIG. 1. The control system includes a thin client terminal1, a management server2used to provide a virtual desktop environment with the thin client terminal1, a dynamic host configuration protocol (DHCP) server3, a VDI server4, and a management console5.

The thin client terminal1is an information processing apparatus that functions as a client to communicate with the management server2, the DHCP server3, and the VDI server4. The thin client terminal1may be a clamshell device like a notebook-type personal computer or may be a slate-type device like a tablet computer. Hereinafter, the thin client terminal1is realized as a notebook-type device.

The thin client terminal1may communicate with the management server2via a network such as wireless LAN or wired LAN. The thin client terminal1may communicate with the DHCP server3that manages lease of IP addresses via the network. The thin client terminal1may communicate with the VDI server4that provides a virtual desktop environment with each of client terminals including the thin client terminal1via the network.

The management server2has a function of verifying whether the thin client terminal1is an authenticated thin client terminal. The management server2also has a function of providing data for a setup process (install information file), and program and information required to communicate with the VDI server4with each thin client terminal1verified as the authenticated thin client terminal. That is, the management server2functions as a client verification site and a download site.

The DHCP server3leases (assigns) an IP address to the thin client terminal1, and provides information related to the leased IP address with the management server2. An IP address is an identification number on the network using TCP/IP protocol, and may be referred to as a network address.

The VDI server4may use several types of techniques to realize a virtual desktop environment. One of them is Virtual Desktop Infrastructure (VDI).

In the present embodiment, VDI may be used as a technique to realize the virtual desktop environment. In that case, the VDI server4functions as a server that provides a virtual desktop environment using VDI. The thin client terminal1functions as a VDI client terminal. The VDI server4provides the virtual desktop environment by receiving operation data on the thin client terminal1and by transmitting image data of the screen of the thin client terminal1(VDI screen data) and image data corresponding to updated parts on the screen. In the thin client terminal1, by displaying the image data on the screen, the desktop environment generated by a virtual machine executed on the VDI server4can be used as if it is a desktop environment operated by the thin client terminal1itself.

The management console5is a terminal for a manager to set a client policy used by the management server2and a VDI policy used by the VDI server4. The management server2has a function of providing, for example, web-based graphical user interface (GUI) used to change and apply the setting of the client policy with the management console5. The VDI server4has a function of providing web-based GUI used to change and apply the setting of the VDI policy with the management console5.

In such a system, when a thin client terminal1in which a setup process (hereinafter, also referred to as setup) has not been performed is booted, the thin client terminal1requires to receive (download) data for the setup process from the management server2. The data for the setup process is used to set (install) various information (parameters) to the thin client terminal1in the setup process, and is served as, for example, an XML-format file. Hereinafter, the data for the setup process may be referred to as a setup file.

In order that the booted thin client terminal1(before executing the setup process) accesses the management server2, it may be considered that an URL of the management server2, a file name of a file to be downloaded, information indicative of a password and the like, are previously set to the thin client terminal1. Such setting may be performed by using a BIOS menu or a configuration file stored in a USB flash memory, or by storing the setting into option data in the DHCP server3, for example.

However, in the method using the BIOS menu or the configuration file stored in the USB flash memory, setting operation must be performed in each thin client terminal1, and a great workload for the setting is required in a system including many thin client terminals1. Furthermore, in the method storing the setting into the option data in the DHCP server3, all thin client terminals connected to the DHCP server3may acquire the setup file from the management server2without any identification process. This method may function well in a system on a local network such as intranet, but may be vulnerable in other system.

Therefore, in the present embodiment, in order that the thin client terminal1receives the setup file from the management server2, information transmitted when the thin client terminal1requests the DHCP server3to lease (assign) an IP address is used.

Specifically, the thin client terminal1sets a production number (also referred to as a serial number) thereof as a host name, and requests the DHCP server3to lease an IP address. The production number to be set may be encrypted. In accordance with the request, the DHCP server3leases an IP address to the thin client terminal1, and provides updated lease information to the management server2.

When the host name included in the lease information corresponds to a production number of a thin client terminal1that is previously registered with the management server2, and if a setup process is not performed to the thin client terminal1yet, the management server2transmits a setup file to the thin client terminal1using the IP address leased to the thin client terminal1. Note that, when the production number set as the host name is encrypted, the management server2decrypts the host name, and determines whether the decrypted host name corresponds to a production number of a thin client terminal1previously registered. When the decrypted host name corresponds to the production number of the thin client terminal1previously registered, and if a setup process is not performed to the thin client terminal1yet, the management server2transmits a setup file to the thin client terminal1. The setup file may be encrypted.

As can be understood from the above, the thin client terminal1, the DHCP server3, and the management server2work in cooperation. Thus, only the registered client terminal1can be subjected to the setup process using information required for the registered thin client terminal1through a simple process via network without performing any operation previously by a manager to the thin client terminal1and/or the DHCP server3. Thus, the workload for the manager can be reduced and the security can be improved.

The functional configurations of the thin client terminal1, the management server2, and the DHCP server3will be explained with reference toFIG. 2.

The thin client terminal1includes a display control module11, a common key generation module12, an encryption/decryption module13, a network processing module14, a setup processing module15, and an information storage area16.

The display control module11controls displaying information that corresponds to a condition of the thin client terminal1and an operation by a user on a screen of a display (for example, LCD) of the thin client terminal1. The user inputs an operation to the thin client terminal1using a keyboard and various pointing devices such as a mouse, a touchpad, and a touch panel.

The display control module11may control displaying as follows.

(1) While the thin client terminal1is being powered on until it is connected to a network, information indicative of processing for network connection (for example, “Connecting to Network”) is displayed.

(2) During the setup process of the thin client terminal1, information indicative of setup (for example, “Setup in progress. Downloading data from Management Server. Please stand by and Do Not turn off device.”), and/or information indicative of progress of the setup (for example, time and amount of process until the completion) is displayed.

(3) Information indicative of success of the setup of the thin client terminal1(for example, “Installed successfully. Rebooted.”) is displayed.

(4) Information indicative of failure of the setup of the thin client terminal1(for example, “Install failure. Please perform setup again.”) is displayed.

Note that the displayed information may be a text or an image.

The common key generation module12generates a common key used for exchanging data with the management server2. The common key generation module12generates a common key by using, for example, a production number161(identification information) recorded in the thin client terminal1.

By using the common key, the encryption/decryption module13encrypts data to be directly or indirectly sent to the management server2, and decrypts data encrypted by the management server2.

The network processing module14controls communication with other devices such as the management server2, DHCP server3, and VDI server4through the network.

Specifically, the network processing module14transmits a request for assignment (lease) of an IP address to the DHCP server3when the thin client terminal1has been turned on. The network processing module14may transmit the request for assignment to the DHCP server3in response to another event such as a user's operation.

The request for assignment includes, when the setup process has been performed to the thin client terminal1, a computer name of the thin client terminal1set as a host name.

On the other hand, when the setup process has not been performed to the thin client terminal1, the request for assignment includes identification information that uniquely identifies the thin client terminal1and is set as a host name. The identification information is, for example, the production number161of the thin client terminal1. The network processing module14reads the production number161from the information storage area16, and transmits to the DHCP server3the request for assignment including the production number161set as the host name.

The network processing module14may set identification information encrypted by the encryption/decryption module13using the common key as the host name in the request for assignment. Alternatively, the production number161encrypted by the encryption/decryption module13using the common key may be used as the identification information.

The network processing module14receives an IP address, which is assigned in accordance with the request for assignment, from the DHCP server3. The network processing module14connects the thin client terminal1to a wireless or wired network using the received IP address, and controls the communication with the other devices.

When the setup process has not been performed, the thin client terminal1transitions to a state to wait for start of the setup process (initial setting) after receiving the IP address. In that case, the network processing module14receives a setup file from the management server2. The setup file may be encrypted. In that case, the encryption/decryption module13decrypts the setup file using the common key.

The setup processing module15analyzes the setup file (or decrypted setup file) and subjects the thin client terminal1to the initial setting. Specifically, the setup processing module15writes one or more items of information (parameters) included in the setup file to the information storage area16. The information storage area16is, for example, a specific storage area in a BIOS-ROM. The one or more items of information may include, for example, a computer name, a URL of the management server2, a URL of the VDI server4, a password, and a client certificate, and other information for the setup.

When setup using the setup file has completed, the network processing module14notifies the management server2of success of the setup, and reboots the thin client terminal1. The thin client terminal1may transition to a normally started state instead of rebooting.

On the other hand, when the setup using the setup file has failed, the thin client terminal1is turned off. For example, if the setup processing module15cannot write information in the setup file to the information storage area16, the failure of setup is recognized.

The setup processing module15may start a timer151when the network processing module14has started receiving the setup file from the management server2. The timer151is used to manage the progress of receiving the setup file and executing setup using the setup file (that is, installing the setup file). In the timer151, a time to detect a timeout while the setup file is being received, and a time to detect a timeout while the setup using the setup file is being executed, are set.

When the timer151has detected a timeout while the setup file is being received, the network processing module14stops receiving the setup file and turns off the thin client terminal1. When the timer151has detected a timeout while the setup using the setup file is being executed, the setup processing module15stops executing the setup and turns off the thin client terminal1.

The DHCP server3includes a lease control module31, a reception control module32, a lease information notification module33, and a transmission control module34. The reception control module32may receive data transmitted from the management server2and the thin client terminal1. The transmission control module34may transmit data to the management server2and the thin client terminal1.

The reception control module32receives, for example, a request for assignment of an IP address from the thin client terminal1. The request for assignment includes a host name.

In accordance with the received request for assignment, the lease control module31selects an IP address from IP addresses that are not assigned yet to any device, and assigns the selected IP address to the thin client terminal1. The lease control module31detects IP addresses assignable to the thin client terminal1by using, for example, lease information35stored in the DHCP server3.

FIG. 3shows a configuration example of the lease information35. The lease information35includes one or more records corresponding to one or more IP addresses managed by the DHCP server3.

Each record includes, for example, an IP address field, a host name field, a lease date and time field, and an expiration date and time field. In a record corresponding to an IP address, the IP address field indicates the IP address. A value such as “192.168.1.1” is set in the IP address field.

The host name field indicates a name given to a host to which the IP address is leased. The host is, for example, the thin client terminal1. When the host notifies the DHCP server3of a host name (for example, “client1”), the host name is set in the host name field. When the host notifies the DHCP server3of a production number (for example, “XXX003”) as the host name, the production number is set in the host name field. Alternatively, when the host notifies the DHCP server3of an encrypted production number (for example, encrypted “XXX003”) as the host name, the encrypted production number is set in the host name field.

The lease date and time field indicates a date and time of when leasing of the IP address to the host starts. A date and time such as “2018/5/24, 8:30” is set in the lease date and time field.

The expiration date and time field indicates a deadline representing when leasing of the IP address is allowed to the host. A date and time such as “2018/5/24, 11:30” is set in the expiration date and time field. The value set in the expiration date and time field may be represented as a period from the lease date and time (for example, days, hours, or the like).

By using a value in the expiration date and time field, or by using values in the lease date and time field and in the expiration date and time field, the lease control module31determines whether the IP address corresponding to each record is currently being assigned to a host or whether the IP address can be assigned to another host since the current date and time reaches the expiration date and time. The DHCP server3assigns an IP address of assignable IP addresses to a new host (thin client terminal1) requiring the assignment.

When an IP address is newly assigned, the lease control module31updates the lease information35using the IP address and the host name in the request for assignment. That is, in the record corresponding to the newly assigned IP address, values of a host name, a lease date and time, and an expiration date and time are set (updated).

Then, the lease control module31notifies the thin client terminal1of the assigned IP address (that is, transmits the assigned IP address to the thin client terminal1) through the transmission control module34.

The lease control module31sends the newly assigned IP address and the host name in the request for assignment to the lease information notification module33. The lease information notification module33transmits the newly assigned IP address and the host name in the request for assignment to the management server2through the transmission control module34. The lease information notification module33may transmit the record corresponding to the newly assigned IP address of the lease information35to the management server2. Alternatively, the lease information notification module33may transmit the lease information35as it is to the management server2.

The lease information notification module33may monitor the lease information35. The lease information notification module33may transmit, when a record in the lease information35is updated, the IP address and the host name in the updated record to the management server2. The monitoring is realized by using, for example, a DHCP command of power shell.

The management server2includes a control module21, a reception control module22, an encryption/decryption module23, a client verification module24, a setup file generation module25, a common key generation module26, a transmission control module27, and a database29. The database29stores setup information29A and thin client information29B.

The setup information29A includes one or more items of information (one or more parameters) that are to be set (installed) in setup process with respect to one or more thin client terminals1, respectively. The one or more thin client terminals1are managed by the management server2. The one or more items of information may include, for example, a computer name, a management server URL, a VDI server URL, a client certificate, a password, and other information to be initially set to the thin client terminal1.

FIG. 4shows a configuration example of the thin client information29B. The thin client information29B includes one or more records corresponding to one or more thin client terminals1managed by the management server2. In other words, the one or more thin client terminals1are registered with the management server2.

Each record includes, for example, a production number field, a computer name field, a state field, a management server URL field, a VDI server URL field, a client certificate field, a common key field, and an information update date and time field.

In a record corresponding to a thin client terminal1, the production number field shows identification information indicative of a production number uniquely assigned for managing the thin client terminal1. Thus, the management server2uniquely identifies each of the thin client terminals1, based on the production number assigned thereto.

Note that, instead of the production number, a different value that uniquely identifies the thin client terminal1(for example, a physical address such as MAC address) may be used.

The computer name field indicates a computer name given to the thin client terminal1. The management server2gives the computer name at the time of setup of the thin client terminal1, for example. The computer name may be used as a host name when the thin client terminal1that has been subjected to the setup requests the DHCP server3to lease an IP address.

The state field shows state information indicative of a state of the thin client terminal1. For example, one of “Pre-setup”, “Normal”, and “Locked” is set in the state field. The “Pre-setup” indicates that the thin client terminal1has not been subjected to the setup (initial setting). The “Normal” indicates that the thin client terminal1has been subjected to the setup and the thin client terminal1functions properly. The “Locked” indicates that the management server2prohibits the thin client terminal1from being booted.

The management server URL field indicates an address on a network used by the thin client terminal1to access the management server2. The VDI server URL field indicates an address on a network used by the thin client terminal1to access the VDI server4after the thin client terminal1is properly booted.

The client certificate field indicates a certificate used by the thin client terminal1to login the VDI server4or to connect to the wireless LAN.

The common key field indicates a common key used in data exchange between the thin client terminal1and the management server2. That is, the common key is used in encryption and decryption of data by the thin client terminal1, and is used in encryption and decryption of data by the management server2.

The data update date and time field indicates an update date and time of registered information (that is, the update date and time of the record) of the thin client terminal1. Based on the update date and time, it is determined whether the registered information (record) is updated after the management server2performed the latest setting, install, and the like to the thin client terminal1.

In the production number field among the above-described fields of the record, for example, the production number of the thin client terminal1is set when an administrator registers the thin client terminal1with the management server2. At the registration, the “Pre-setup” may be set in the state field of the record. On the other hand, no value is set in the other fields of the computer name, the management server URL, the VDI server URL, the client certificate, the common key, and the data update date and time at the registration, but values are set thereto when the setup has been completed in the thin client terminal1. Thus, in the record corresponding to the thin client terminal1that has been subjected to the setup, values are set in all fields.

As shown inFIG. 2, the control module21controls the operation of each component in the management server2. The control module21may receive data transmitted from the DHCP server3or the thin client terminal1through the reception control module22. The control module21may transmit data to the DHCP server3or the thin client terminal1through the transmission control module27.

The common key generation module26generates a common key to be used in data exchange with each of thin client terminals1registered with the management server2. The common key generation module26may generate a common key using, for example, a production number (identification information) of each thin client terminal1included in the thin client information29B. The common key generation module26and the common key generation module12of the thin client terminal1generate the same common key using the production number of the thin client terminal1.

By using the common key of the thin client terminal1, the encryption/decryption module23encrypts data to be sent to the thin client terminal1, and decrypts data encrypted by the thin client terminal1.

The client verification module24verifies whether a terminal requesting the DHCP server3to assign an IP address is a thin client terminal1registered with the management server2using the thin client information29B.

The setup file generation module25generates a setup file corresponding to each thin client terminal1using the setup information29A. The setup file includes information (parameters) to be set (installed) to the corresponding client terminal1. The information to be set may include, as described above, a URL of the management server2, a URL of the VDI server4, a password, a client certificate, and other information for setup. When the process using the setup file is performed on the thin client terminal1, the information (parameters) is stored into a specific storage area (for example, BIOS area).

Now, the operations of each component when the control module21receives an IP address and a host name from the DHCP server3through the reception control module22will be explained. The control module21sends the received host name to the encryption/decryption module23.

The common key generation module26, the encryption/decryption module23, and the client verification module24determine whether the received host name corresponds to one of the thin client terminals1registered with the management server2by using the thin client information29B. That is, whether a terminal having the received host name is a thin client terminal1registered with the management server2is determined.

Specifically, the common key generation module26and the client verification module24read a record from the thin client information29B. The common key generation module26generates a common key by using a production number indicated by the record. The encryption/decryption module23decrypts the received host name by using the generated common key. Then, the client verification module24determines that the received host name corresponds to the thin client terminal1registered with the management server2when the production number indicated by the record matches the decrypted host name.

On the other hand, when the production number indicated by the record does not match the decrypted host name, a different record is read from the thin client information29B, and whether the received host name corresponds to another thin client terminal1registered with the management server2is determined using the different record. When a production number does not match the decrypted host name with respect to all of the records in the thin client information29B, the client verification module24determines that the received host name does not correspond to any of the thin client terminals1registered with the management server2.

When the received host name corresponds to the thin client terminal1registered with the management server2, the client verification module24determines whether the thin client terminal1has been subjected to setup. Based on the corresponding record in the thin client information29B that includes the state field in which “Pre-setup” is set, or that includes the management server URL field and the common key field in which no value is set, the client verification module24may determine that the corresponding thin client terminal1has not been subjected to the setup (initial setting) yet.

When the thin client terminal1has not been subjected to the setup, the setup file generation module25generates a setup file to be used for setup of the thin client terminal1by using the setup information29A. The setup file may include a computer name, a URL of management server2, a URL of VDI server4, a password for the thin client terminal1, a client certificate, and the like. The encryption/decryption module23may encrypt the generated setup file by using the common key.

The control module21transmits the setup file (or encrypted setup file) to the thin client terminal1through the transmission control module27. The transmission control module27transmits the setup file to the thin client terminal1via P2P communication by using, for example, the IP address received from the DHCP server3together with the host name.

Then, the control module21may set “Install waiting” in the state field of the record corresponding to the thin client terminal1in the thin client information29B. The control module21includes a result wait timer211. The control module21starts the result wait timer211in response to transmission of the setup file to the thin client terminal1. In the result wait timer211, a time to detect a timeout during the standby waiting for a notification of setup completion from the thin client terminal1is set.

When receiving the notification indicative of setup completion using the setup file from the thin client terminal1through the reception control module22, the control module21sets “Normal” in the state field in the record corresponding to the thin client terminal1in the thin client information29B, and sets values in the computer name field, the management server URL field, the VDI server URL field, the client certificate field, the common key field, and the data update date and time field, respectively.

FIG. 5shows an example where “Normal” is set in the state field in the record (of the thin client information29B) corresponding to the thin client terminal1having the production number “XXX003” ofFIG. 4in accordance with the completion of setup. As shown inFIG. 5, in the record of the thin client terminal1having the production number “XXX003”, values corresponding to the thin client terminal1are set in the computer name field, the management server URL field, the VDI server URL field, the client certificate field, the common key field, and the data update date and time field, respectively.

Note that, when the result wait timer211has detected the timeout during the standby waiting for a result of setup from the thin client terminal1, the control module21resets “Pre-setup” in the state field in the record corresponding to the thin client terminal1in the thin client information29B.

The management server2may further include a lease information requesting module28in order to request the DHCP server3to transmit lease information35. The lease information requesting module28requests transmission of lease information35to the DHCP server3through the transmission control module27. The lease information requesting module28transmits a DHCP command to acquire the lease information35to the DHCP server3at certain intervals or in response to a request from the control module21, for example.

The lease control module31of the DHCP server3transmits the lease information35to the management server2through the transmission control module34in accordance with the DHCP command received by the reception control module32. For example, when the lease information requesting module28(management server2) requests the lease information35after an IP address is assigned to a thin client terminal1, the lease control module31transmits the lease information35including the assigned IP address and the host name of the thin client terminal1to the management server2.

The lease information requesting module28receives the lease information35through the reception control module22. The lease information requesting module28compares the lease information35acquired in the last request to the lease information35acquired in the current request to detect a changed record therebetween. Then, the lease information requesting module28transmits the detected record(s) to the control module21. Thus, as in a case where the host name and the IP address are received from the DHCP server3through the reception control module22, a process to perform setup to a thin client terminal1that is registered with the management server2but has not been subjected to the setup is executed.

Note that, in that case, the DHCP server3may not include the lease information notification module33, and the lease control module31directly transmits the lease information35to the management server2. That is, the functions of the control system of the present embodiment can be achieved using the DHCP server including a conventional configuration for assignment of IP addresses without changing any configuration. Thus, the management server2and the thin client terminal1can easily be introduced into an environment with the DHCP server3.

Furthermore, the common key generation module26may generate a common key before the thin client terminal1is booted, by using a production number of each thin client terminal1included in the thin client information29B. At that time, the encryption/decryption module23may generate the encrypted production number beforehand by using the generated common key. Thus, by simply comparing the host name received from the DHCP server3to the encrypted production number generated beforehand, the client verification module24can determine whether the host name corresponds to a thin client terminal1registered with the management server2.

Note that, as the host name transmitted from the thin client terminal1to the DHCP server3and transmitted from the DHCP server3to the management server2, an unencrypted production number may be set. In that case, the control module21sends the host name to the client verification module24without sending it to the encryption/decryption module23. The client verification module24determines whether the host name corresponds to the thin client terminal1registered with the management server2by using the thin client information29B. The client verification module24determines that the host name corresponds to the thin client terminal1registered with the management server2when the thin client information29B includes a record in which the production number corresponding to the host name received from the DHCP server3is set, for example.

With the above-described configuration, workload for setup of the thin client terminal1can be reduced. Identification information such as a production number of the thin client terminal1is sent from the thin client terminal1to the management server2through the DHCP server3. The management server2can determine whether the terminal to which the IP address is assigned by the DHCP server3is a thin client terminal1registered with the management server2and setup of which is not performed. The management server2transmits a setup file for setup to the thin client terminal1that is registered and setup of which is not performed. In the thin client terminal1, setup is performed using the setup file.

Since information including a URL of the management server2and a file name of a setup file to be acquired are not required to be set to a thin client terminal1before it is operated in the system, the workload for setup can be reduced. Furthermore, since the setup file is exclusively sent to thin client terminals1managed by the management server2, the system can be secured.

The procedure of a boot control process executed by the thin client terminal1will be explained with reference to a flowchart ofFIG. 6.

In response to turning on, the thin client terminal1displays information indicative of “Connecting network” on the screen (step S101). Then, the thin client terminal1determines whether the thin client terminal1is in a pre-setup state where setup thereof has not been completed (step S102). The thin client terminal1determines that it is in the pre-setup state when no parameter has been set to the information storage area16(specific storage area in BIOS), for example.

When the thin client terminal1is not in the pre-setup state (NO in step S102), the thin client terminal1sets a computer name as a host name and requests the DHCP server3to lease an IP address (step S103). Then, the thin client terminal1determines whether an IP address has been received from the DHCP server3(step S104). When an IP address has not been received (NO in step S104), the process returns to step S104and whether an IP address has been received from the DHCP server3is determined again.

When an IP address has been received (YES in step S104), the thin client terminal1is normally started up using the received IP address. The thin client terminal1normally started up connects to the management server2. After the thin client terminal1is authenticated as a proper thin client terminal, the thin client terminal1connects to the VDI server4to function as a VDI client terminal with which a virtual desktop environment is provided.

On the other hand, when the thin client terminal1is in the pre-setup state (YES in step S102), the thin client terminal1generates a common key (step S105). If a common key has already been generated, step S105may be skipped. The thin client terminal1encrypts a production number of the thin client terminal1by using the common key (step S106). Then, the thin client terminal1sets the encrypted production number as the host name and requests the DHCP server3to lease an IP address (step S107).

Then, the thin client terminal1determines whether an IP address has been received from the DHCP server3(step S108). When an IP address has not been received (NO in step S108), the process returns to step S108, and whether an IP address has been received from the DHCP server3is determined again.

On the other hand, when an IP address has been received (YES in step S108), the thin client terminal1performs a setup process (step S109). An example of the procedure of the setup process will be explained with reference to a flowchart ofFIG. 7.

Firstly, the thin client terminal1displays information indicative of “Setup in progress” on the screen and sets (starts) the timer151(step S201). The timer151is a timer to manage the progress of the setup process. For example, a time to detect a timeout during the reception of a setup file, and a time to detect a timeout during the setup using the setup file, are set to the timer151.

The thin client terminal1receives the setup file transmitted from the management server2(step S202). Then, the thin client terminal1determines whether the reception of the setup file has been completed (step S203). When the reception of the setup file has not been completed (NO in step S203), and when the timer151has not detected a timeout (NO in step S208), the reception of the setup file in step S202is continued.

When the reception of the setup file has been completed (step S203), the thin client terminal1decrypts the setup file using the common key and performs setup thereof using the decrypted setup file (step S204).

Then, the thin client terminal1determines whether the setup has been completed (step S205). When the setup has not been completed (NO in step S205), and when the timer151has not detected a timeout (NO in step S211), the setup in step S204is continued.

When the setup has been completed (YES in step S205), the thin client terminal1displays information indicative of “Setup success” on the screen, and notifies the management server2of the completion of setup (step S206).

Then, the thin client terminal1determines whether ACK indicative of acknowledgement has been received from the management server2(step S207). When ACK has not been received (NO in step S207), the process returns to step S207and whether ACK has been received is determined again. On the other hand, when ACK has been received (YES in step S207), the thin client terminal1is rebooted. In response to the reboot, the thin client terminal1proceeds to step S101of the flowchart ofFIG. 6or normally started up.

Note that, when the timer151has detected a timeout during the reception of the file (YES in step S208), or when the timer151has detected a timeout during the setup (YES in step S211), the thin client terminal1displays information indicative of “Setup failure” (step S209), and the thin client terminal1is turned off.

A flowchart ofFIG. 8shows the procedure of a lease control process executed by the DHCP server3.

Firstly, the DHCP server3determines whether a request for lease of an IP address has been received from the thin client terminal1(step S31). When a request for lease of an IP address has not been received (NO in step S31), the process returns to step S31, and whether a request for lease of an IP address has been received is determined again.

On the other hand, when a request for lease of an IP address has been received (YES in step S31), the DHCP server3acquires an IP address that is not used (unleased) and leases the IP address to the thin client terminal1(step S32). The IP address leased is sent to the thin client terminal1. The DHCP server3updates a record corresponding to the leased IP address in lease information35(step S33). Specifically, the DHCP server3sets a host name included in the request for lease to the host name field of the record, sets a date and time of starting lease to the lease date and time field of the record, and sets an expiration date and time of lease to the expiration date and time field of the record.

Then, the DHCP server3transmits the leased IP address and the host name of the thin client terminal1(or the IP address and the host name included in the updated record) to the management server2(step S34). The DHCP server3may transmit the lease information35as it is to the management server2, or the record updated in step S33to the management server2.

A flowchart ofFIG. 9shows another example of the procedure of the lease control process executed by the DHCP server3.

Firstly, the DHCP server3determines whether a request for transmission of lease information35has been received from the management server2(step S41). When a request for transmission of lease information35has not been received (NO in step S41), the process returns to step S41, and whether a request for transmission of lease information35has been received is determined again.

On the other hand, when a request for transmission of lease information35has been received (YES in step S41), the DHCP server3transmits the lease information35to the management server2(step S42). The DHCP server3may transmit the lease information35as it is to the management server2, or only the records updated after the request for transmission is received at the last time may be transmitted to the management server2amongst the all records in the lease information35. Alternatively, values of the IP address field and the host name field of each record updated after the request for transmission is received at the last time may be transmitted.

As can be understood from the above, the DHCP server3may transmit the lease information35or a part thereof to the management server2in accordance with the request from the management server2.

An example of the procedure of a setup control process executed by the management server2will be explained with reference to a flowchart ofFIG. 10.

The management server2determines whether an IP address and a host name have been received from the DHCP server3(step S501). Note that the management server2may determine whether a record of the lease information35including an IP address and a host name has been received. When an IP address and a host name have not been received (NO in step S501), the process returns to step S501, and whether an IP address and a host name have been received is determined again.

When an IP address and a host name have been received (YES in step S501), the management server2reads a record corresponding to a thin client terminal1from the thin client information29B (step S502). The management server2generates a common key of the thin client terminal1using a value of the production number field in the read record (step S503). The generated common key may be stored into the database29or the like. If a common key has already been generated beforehand, or if a common key has already been generated in a setup control process for a different terminal, the common key of the thin client terminal1may be stored into the database29or the like. In that case, step S503may be skipped. The management server2decrypts the received host name using the generated common key (step S504).

Then, the management server2determines whether the terminal corresponding to the decrypted host name is a thin client terminal1registered with the management server2using the decrypted host name and the information of the production number field in the read record (step S505). The management server2determines that the terminal corresponding to the decrypted host name is the thin client terminal1registered with the management server2when the decrypted host name and the information of the production number field in the read record match. On the other hand, the management server2determines that the terminal corresponding to the decrypted host name is a terminal which is not registered with the management server2when the decrypted host name and the information of the production number field in the read record do not match.

When the terminal corresponding to the decrypted host name is a terminal which is not registered with the management server2(NO in step S505), the management server2determines whether the thin client information29B includes another record to be processed (step S506). When the thin client information29B includes another record (YES in step S506), the process returns to step S502. That is, the received host name is decrypted using the another record, and whether the terminal of the decrypted host name is a thin client terminal1corresponding to the another record will be determined. On the other hand, when the thin client information29B does not include any record to be processed (NO in step S506), that is, when steps S502to S505are performed for all of the records in the thin client information29B, it means that the terminal of the received host name does not correspond to any thin client terminal1registered with the management server2. Thus, the process ends.

When the terminal corresponding to the decrypted host name is a thin client terminal1registered with the management server2(YES in step S505), the management server2determines whether the thin client terminal1is in a pre-setup state using the information of the state field in the thin client information29B (step S507). The management server2determines that the thin client terminal1is in the pre-setup state when the record includes the decrypted host name set in the production number field and includes “Pre-setup” set in the state field. The management server2may determine that the thin client terminal1is in a post-setup state when “Normal” or “Locked” is set in the state field of the record.

When the thin client terminal1is in a post-setup state (NO in step S507), the process ends.

When the thin client terminal1is in a pre-setup state (YES in step S507), the management server2generates a setup file for the thin client terminal1using the setup information29A (step S508). The management server2encrypts the generated setup file using the common key (step S509). Then, the management server2transmits the encrypted setup file to the thin client terminal1(step S510), and performs a setup result control process for processing a result of setup by the thin client terminal1(step S511). An example of the procedure of the setup result control process will be explained with reference to a flowchart ofFIG. 11.

Firstly, the management server2sets “Setup waiting” indicative of a standby waiting for setup by the thin client terminal1in the state field of the record corresponding to the thin client terminal1in the thin client information29B (step S551). Then, the management server2sets (starts) the result wait timer211(step S552).

Then, the management server2determines whether a notification of setup completion has been received from the thin client terminal1(step553). When the notification of setup completion has been received (YES in step S553), the management server2sets “Normal” as the state of thin client terminal1(step S554). That is, the management server2sets “Normal” in the state field of the record corresponding to the thin client terminal1in the thin client information29B. Then, the management server2transmits ACK to the thin client terminal1(step S555) and ends the process.

On the other hand, when the notification of setup completion has not been received (NO in step S553), the management server2determines whether the result wait timer211has detected a timeout (step S556). When the result wait timer211has not detected a timeout (NO in step S556), the process returns to step S553, and a process of standby waiting for the notification of setup completion from the thin client terminal1is continued.

When the result wait timer211has detected a timeout (YES in step S556), the management server2sets “Pre-setup” as the state of thin client terminal1(step S557) and ends the process. That is, the management server2sets “Pre-setup” in the state field of the record corresponding to the thin client terminal1in the thin client information29B.

With the above-described configuration, the management server2receives an IP address and a host name of a terminal requesting the DHCP server3to lease an IP address from the DHCP server3and determines whether the terminal is a thin client terminal1registered with the management server2and is in a pre-setup state. Then, when the terminal is a thin client terminal1registered with the management server2and is in a pre-setup state, the management server2can cause the thin client terminal1to perform setup by transmitting a setup file to the thin client terminal1. Since information including a URL of the management server2and a file name of a setup file is not required to be set to the thin client terminal1beforehand, workload for setup of the thin client terminal1can be reduced.

Note that the management server2may determine whether the lease information35has been received from the DHCP server3in step S501. In that case, the management server2detects, from records in the newly received lease information35, records that have been updated from the records in the lease information35received from the DHCP server3at the last transmission. Then, the management server2performs steps S502and thereafter using an IP address and a host name included in each record detected. Thus, a similar setup control process can be performed if the lease information35is received as it is from the DHCP server3.

FIG. 12shows an example of a system configuration of the thin client terminal1.

The thin client terminal1includes a CPU101, a system controller102, a main memory103, a BIOS-ROM104, an LCD105, a speaker106, a communication device107, an embedded controller (EC)108, and a USB connector109.

The CPU101is a processor that executes a BIOS and an embedded OS stored in the BIOS-ROM104, various programs downloaded in the main memory103, and the like.

The system controller102is a bridge device connecting between the CPU101and each component. The system controller102controls data transfer with various devices that are connected to the USB connector109. The device is, for example, a USB flash memory. In that case, the system controller102controls write/read of data to/from the USB flash memory.

Furthermore, the system controller102includes a display controller that controls the LCD105used as a display monitor of the thin client terminal1. The display signal generated by the display controller is sent to the LCD105. The LCD105displays a screen image based on the display signal. On the screen of the LCD105, information may be displayed in accordance with the state of the thin client terminal1and an operation by a user.

The system controller102further includes an audio controller that controls the speaker106. The audio signal generated by the audio controller is sent to the speaker106. The speaker106outputs a sound based on the audio signal.

The communication device107performs wired or wireless communication. The communication device107includes a transmitter that transmits signals and a receiver that receives signals. The EC108functions as a power controller that executes power management to turn on or off the client terminal1.

FIG. 13shows an example of the system configuration of the management server2and the DHCP server3.

Each of the servers2and3includes a CPU201, a system controller202, a main memory203, a BIOS-ROM204, a nonvolatile memory205, a communication device207, and an embedded controller (EC)208.

The CPU201is a processor that executes a BIOS stored in the BIOS-ROM204, an OS and various programs loaded from the nonvolatile memory205to the main memory203, and the like. Data used in each of the servers2and3may be stored into the nonvolatile memory205. For example, in the management server2, a part of the storage area of the nonvolatile memory205is used as a database29in which the setup information29A and the thin client information29B may be stored. Furthermore, in the DHCP server3, the lease information35may be stored into the nonvolatile memory205.

The system controller202is a bridge device connecting between the CPU201and each component.

The communication device207performs wired or wireless communication. The communication device207includes a transmitter that transmits signals and a receiver that receives signals. The EC208functions as a power controller that executes power management to turn on or off each of the servers2and3.

As explained above, according to the embodiment, workload for setup can be reduced. The thin client terminal1transmits a request for assignment of an IP address to the DHCP server3. The request for assignment includes first identification information (for example, a production number, an encrypted production number, or the like) that uniquely identifies the thin client terminal1and is set as a first host name. In accordance with the request for assignment, the DHCP server3assigns a first IP address to the thin client terminal1and transmits the first IP address and the first host name of the thin client terminal1to the management server2. In the management server2, one or more items of second identification information that uniquely identify each of one or more client terminals to which setup should be performed are stored into the database29(nonvolatile memory205). The management server2receives the first IP address and the first host name from the DHCP server3. When the one or more items of second identification information include the first identification information set as the first host name, and when setup of the thin client terminal1corresponding to the first identification information has not been performed, the management server2transmits data for setup to the thin client terminal1using the first IP address.

In the thin client terminal1, setup is performed using the transmitted data for setup. Thus, a URL of the management server2and a file name of the data for setup are not required to be set into the thin client terminal1or the DHCP server3beforehand, and thus, workload for setup can be reduced.

Second Embodiment

The first embodiment discloses a configuration for setup of setting information of a thin client terminal1. In the second embodiment, a configuration for updating setting information set to the thin client terminal1will be explained.

A control system1of the second embodiment is the same as the control system1of the first embodiment, and only the procedure of updating the setting information performed by the thin client terminal1, the management server2, and the management console5is different from the first embodiment. Hereinafter, differences from the first embodiment will be mainly explained.

A manager may need to update the setting information set to the thin client terminal1(in the setup, for example) to conform to various changes with respect to the thin client terminal1or the management server2. The changes may be, for example, changes to a user, a hardware configuration, a software configuration, a using environment, a usage, or the like related to the thin client terminal1and/or the management server2.

In the present embodiment, as shown inFIG. 14, the management server2can update setting information163set to the thin client terminal1in accordance with an operation by the manager using the management console5. New setting information to update the setting information163is created using thin client information29B used for managing information set to each thin client terminal1and group information29C used for managing information set to each group to which the thin client terminal1belongs. The management server2distributes the created setting information to the thin client terminal1. The thin client terminal1replaces the setting information163as being set (in the setup, for example) with the distributed setting information to update the setting information163.

Specifically, the thin client terminal1stores the setting information163and a setting information update date and time162that are included in first data transmitted by the management server2, in an information storage area16. The setting information update date and time162indicates a first date and time of when the management server2generates the setting information163. The first data is used for, for example, setup. The data for setup is described in the first embodiment.

When the thin client terminal1is booted (turned on, for example) after the setting information163and the setting information update date and time162indicative of the first date and time are stored in the information storage area16, the thin client terminal1transmits second data to the management server2. The second data includes a transmission request of a second date and time of when the management server2updates the setting information. In the management server2, the update of the setting information to be distributed to the thin client terminal1is, for example, performed in accordance with an operation via the management console5. The management server2transmits, when the second data is received from the thin client terminal1, third data including the second date and time to the thin client terminal1.

The thin client terminal1receives the third data from the management server2. When the second date and time included in the third data is different from the first date and time indicated by the setting information update date and time162, the thin client terminal1transmits fourth data including a transmission request of updated setting information to the management server2. The management server2transmits, when the fourth data is received form the thin client terminal1, fifth data including the updated setting information to the thin client terminal1.

The thin client terminal1receives the fifth data from the management server2, updates the setting information163stored in the information storage area16with the updated setting information included in the fifth data, and updates the setting information update date and time162stored in the information storage area16with the second date and time. Thus, the manager can easily update the setting information163set to the thin client terminal1.

Now, a functional configuration of the thin client terminal1, the management server2, and the management console5will be explained.

As shown inFIG. 14, the management server2includes a control module21, a transmission control module27, an encryption/decryption module23, a client verification module24, a transmission data generation module251, a setting information update module252, a reception control module22, and a database29. The database29stores thin client information29B including information set to each thin client terminal1and group information29C including information set to a group to which one or more thin client terminals1belong. The management server2further includes a management website215that processes a web access by the management console5and a download site216that processes a download request of a file by the thin client terminal1.

The control module21controls operations of each component in the management server2. The control module21may receive data transmitted from the thin client terminal1via the reception control module22. The control module21may transmit data to the thin client terminal1via the transmission control module27. The reception control module22and the transmission control module27communicate with the thin client terminal1through, for example, a communication procedure based on HTTP or HTTPS.

The encryption/decryption module23may encrypt data to be transmitted to the thin client terminal1and decrypt data encrypted by the thin client terminal1, by using a common key of the thin client terminal1. The encryption/decryption system used here may be AES256 or the like.

The client verification module24verifies whether a terminal is one of the thin client terminals1registered with the management server2using the thin client information29B.

FIG. 15shows a configuration example of the thin client information29B. The thin client information29B includes one or more records corresponding to one or more thin client terminals1managed by the management server2. That is, the one or more thin client terminals1are registered with the management server2.

Each record includes, for example, fields of a production number, a computer name, a group name, a state, an identifier, a user certificate (client certificate), a private key, a private password, a common key, and an update date and time.

In a record corresponding to a thin client terminal1, a production number field shows identification information indicative of a production number uniquely assigned for managing the thin client terminal1. Thus, the management server2uniquely identifies each of the thin client terminals1, based on the production number assigned thereto. Note that, instead of the production number, a different value that can uniquely identify the thin client terminal1(for example, a physical address such as MAC address) may be used.

A computer name field indicates a computer name given to the thin client terminal1. The computer name is given by the management server2at the time of setup of the thin client terminal1, for example. The computer name may be used as a host name when the thin client terminal1connects to a network. For example, when the thin client terminal1that has been subjected to the setup requests the DHCP server3to lease an IP address, the computer name is used as a host name.

A group name field indicates a group name to which the thin client terminal1belongs. Using a value set in the group name field, the record in the group information29C including information to be set to the thin client terminal1is identified. A configuration of the group information29C will be described later with reference toFIG. 16.

A state field shows state information indicative of a state of the thin client terminal1. In the state field, for example, any of “Pre-setup”, “Normal”, and “Locked” is set. The “Pre-setup” indicates that the thin client terminal has not been subjected to the setup (initial setting). The “Normal” indicates that the thin client terminal1has been subjected to the setup and the thin client terminal1operates properly. The “Locked” indicates that the management server2prohibits the thin client terminal1from being booted.

An identifier field, a user certificate field, a private key field, and a private password field indicate information related to security setting of wireless local area network (LAN) connection (or wired LAN connection). The identifier field indicates an identifier used in authentication (for example, EAP-TLS authentication) when the thin client terminal1connects to wireless LAN.

The user certificate field indicates an electronic certificate used in the authentication. In the user certificate field, a file name of a file including an electronic certificate used in the authentication is set, for example. The file of electronic certificate is stored into the database29, for example. The file of the electronic certificate includes information indicative of the date and time of when the file is created or updated.

The private key field indicates a key used in the authentication. In the private key field, a file name of a file including a key used for the authentication is set, for example. The file of the key is stored into the database29, for example. The file of the key includes information indicative of the date and time of when the file is created or updated.

The private password field indicates a password used in the authentication.

The information in the identifier field, the user certificate field, the private key field, and the private password field may be used in login to a VDI server4or the like.

A common key field indicates a common key used in data exchange between the thin client terminal1and the management server2. That is, the common key is used in encryption and decryption of data by the thin client terminal1, and in encryption and decryption of data by the management server2.

An update date and time field shows an update date and time of when the management server2updates (or creates) setting information to be set to the thin client terminal1. The update date and time indicates, for example, an update date and time of a record in thin client information29B corresponding to the thin client terminal1or of a record in the group information29C corresponding to a group to which the thin client terminal1belongs. Based on the update date and time, whether the setting information163currently being set to the thin client terminal1is latest may be determined.

FIG. 16shows a configuration example of group information29C. The group information29C includes one or more records corresponding to one or more groups managed by the management server2. One or more thin client terminals1belong to each group.

Each record includes, for example, fields of a group name, a management server URL, a download server URL, a VDI server URL, a BIOS setting kitting file name, a number of retry, a retry interval, a polling interval, an action upon disconnection, and a domain.

In a record corresponding to a group, a group name field indicates a name given to the group. In the group name field, a name that uniquely identifies the group is set.

A management server URL field indicates an address on a network used by a thin client terminal1of the group to access the management server2that manages the thin client terminal1.

A download server URL field indicates an address on a network used by a thin client terminal of the group to access a download server. In the download server URL field, for example, an URL to access the download site216on the management server2is set. By accessing the management server2with the URL set in the download server URL field and the file name of the file arranged in the management server2(download site216), the file with the file name can be downloaded from the management server2.

A VDI server URL field indicates an address on the network to access the VDI server4after a thin client terminal1of the group is booted properly.

A BIOS setting kitting file name field indicates a file name of a file to set basic input/output system (BIOS) of a thin client terminal1of the group. The file for the BIOS setting is, for example, stored into the database29. The file to set BIOS includes information indicative of a date and time of when the file is created or updated.

A number of retry field, a retry interval field, a polling interval filed, an action upon disconnection field, and a domain field indicate information related to communication setting.

A number of retry field indicates an upper limit number of polling retries (for example, ten times) by a thin client terminal1of the group performed when the management server2does not respond to a polling by the thin client terminal1. A retry interval field indicates an interval between polling retries to the management server2by a thin client terminal1of the group (for example, thirty seconds). A polling interval field indicates an interval between polling operations to the management server2performed by a thin client terminal1of the group (for example, ten seconds).

An action upon disconnection field indicates an action by a thin client terminal1of the group performed when the thin client terminal1retries polling by the number of retry. The action may be, for example, power off or screen lock. In the screen lock state, the thin client terminal does not accept any operation. In the power off state and the screen lock state, an illegal usage of the thin client terminal1can be prevented.

A domain field indicates a domain name of the group on a network. With the domain name indicated in the domain field, each thin client terminal1of the group is managed.

The management server2updates at least one of the thin client information29B or the group information29C in accordance with an operation of the manager using the management console5. In the following description, the operations of the management server2and the management console5to update the thin client information29B and the group information29C will be explained.

The management website215is a website that provides an interface to update the thin client information29B and the group information29C with the manager. The management website215generates a webpage to update at least one of the thin client information29B or the group information29C in cooperation with the setting information update module252. The management console5accesses the management website215in response to the operation by the manager.

The management console5is a terminal operated by a manager and may be realized as a personal computer, for example. The management console5has a function to communicate with the management server2through a network.

For example, a web browser51executing on the management console5realizes an access to the management website215on the management server2. That is, when the manager performs an operation to execute the web browser51on the management console5and performs an operation to access the management website215using the web browser51, the management console5can be connected to the management website215.

The web browser51receives, for example, data of a web page to update at least one of the thin client information29B or the group information29C from the management website215, and displays the web page on a screen. In accordance with an operation on the web page to change at least a part of the thin client information29B and the group information29C, the web browser51transmits data indicative of the changed content to the management website215.

By using the data indicative of the changed content, the management website215updates at least one of the thin client information29B or the group information29C in cooperation with the setting information update module252.

An example of an interface to update the thin client information29B and the group information29C will be explained with reference toFIGS. 17 and 18.

FIG. 17shows an example of a web page61to edit the thin client information29B of each thin client terminal1, displayed on a screen of the management console5. A manager operates the management console5to execute the web browser51, for example. Then, the manager operates the web browser51to access a specific address (URL) in the management website215.

The specific address is an address of a web page to edit a record of the thin client information29B corresponding to a thin client terminal1. In response to an access to the specific address, the management server2transmits data of a web page corresponding to the address to the management console5. Thus, in a window of the web browser51, the web page61to edit the record of the thin client information29B corresponding to the thin client terminal1is displayed.

The web page61includes, in order to edit a record of the thin client information29B corresponding to a chin client terminal1, display areas611and612corresponding to fields comprising the record, and text input areas613and614showing values set in the fields. A manager may perform an operation to change a value shown in each of the text input areas613and614. Note that, values currently being set in the fields in the record of the thin client information29B stored in the management server2are displayed in the text input areas613and614in a condition before being changed by the manager.

Specifically, the display areas611include display areas of a computer name, a production number, a group name, and a state. The text input areas613show values to be set as the computer name, the production number, the group name, and the state, respectively.

The display areas612include display areas of an identifier, a user certificate, a private key, and a private password that are related to LAN security setting. The text input areas614show values to be set as the identifier, the user certificate, the private key, and the private password, respectively.

With the display areas611and612, and with the text input areas613and614, the manager can check the values set in the fields and can perform an operation to change each of the values. The value changed by the operation is transmitted from the management console5to the management server2, and is reflected upon the corresponding record of the thin client information29B. Thus, the manager can freely change the record of the thin client information29B corresponding to each thin client terminal1by the operation using the web page61.

FIG. 18shows an example of a web page62to edit group information29C of each group displayed on a screen of the management console5. The manager operates the management console5to execute the web browser51on the management console5, for example. Then, the manager operates the web browser51to access a specific address (URL) in the management website215.

The specific address is an address of a web page to edit a record of the group information29C corresponding to a group. In response to an access to the specific address, the management server2transmits data of a web page corresponding to the address to the management console5. Thus, in a window of the web browser51, the web page62to edit the record of the group information29C corresponding to the group is displayed.

The web page62includes, in order to edit a record of the group information29C corresponding to a group, a display area621showing a name of the group, display areas622and623corresponding to fields in the record, and text input areas624and625showing values set in the fields. A manager may perform an operation to change a value shown in each of the text input areas624and625. Note that, values currently being set in the fields in the record of the group information29C stored in the management server2are displayed in the text input areas624and625in a condition before being changed by the manager.

Specifically, the display areas622include display areas of a management server URL, a download server URL, a VDI server URL, and a BIOS setting kitting file name. The text input areas624show values to be set as the management server URL, the download server URL, the VDI server URL, and the BIOS setting kitting file name, respectively.

The display areas623include display areas for the number of retry, a retry interval, a polling interval, an action upon disconnection, and a domain that are related to communication setting. The text input areas625show values set as the number of retry, the retry interval, the polling interval, the action upon disconnection, and the domain, respectively.

With the display areas622and623, and with the text input areas624and625, the manager can check the values set in the fields and can perform an operation to change each of the values. The value changed by the operation is transmitted from the management console5to the management server2, and is reflected upon the corresponding record of the group information29C. Thus, the manager can freely change the record of the group information29C corresponding to each group by the operation using the web page62.

As above, the web browser51of the management console5transmits the contents of operations using the web pages61and62to the management website215. That is, a changed content of a record of the thin client information29B using the web page61and a changed content of a record of the group information29C using the web page62are transmitted from the web browser51to the management website215.

The setting information update module252of the management server2updates the record of the thin client information29B and the record of the group information29C using the changed contents sent to the management website215. Thus, the manager can easily edit the record of the thin client information29B or the record of the group information29C by an operation via the management console5.

Furthermore, when a record of the thin client information29B is updated, the setting information update module252updates the date and time set in an update date and time field in the record to the date and time of when the update is performed. In the example ofFIG. 15, when updating at least one field in a record that is included in the thin client information29B and includes “XXX001” set in the production number field, the update date and time field in the record is changed from “2018/5/16 10:00” to the date and time of when the update is performed.

Furthermore, when a record in the group information29C is updated, the setting information update module252specifies a thin client terminal1that belongs to a group corresponding to the record. Then, in the record of the thin client information29B corresponding to the specified thin client terminal1, the setting information update module252updates the date and time set in the update date and time field to a date and time of when the record of the group information29C is updated.

In the example ofFIGS. 15 and 16, when a record of the group information29C including “group1” set in the group name field is updated, thin client terminals1that belong to “group 1” are specified by using the thin client information29B. One of the specified thin client terminals1corresponds to a first record of the thin client information29B including “group 1” set in the group name field and “XXX001” set in the production number field. The other of the specified thin client terminals1corresponds to a second record of the thin client information29B including “group 1” set in the group name field and “XXX002” set in the production number field. Then, in each of the first and second records, the date and time set in the update date and time is changed to a date and time of when the record of the group information29C including “group1” set in the group name field is updated.

The management server2distributes the setting information generated by using the updated thin client information29B and the updated group information29C to the thin client terminal1. The thin client terminal1updates the setting information163by replacing the setting information163currently being set (by, for example, setup) with the distributed setting information.

Operations of the thin client terminal1and the management server2to update the setting information163in the thin client terminal1will be explained. Here, assume that the setting information163and the setting information update date and time162that indicates a first date and time of when the management server2generates the setting information163, are stored into the information storage area16in the thin client terminal1using the first data (for example, data for setup) transmitted from the management server2.

The control module21receives second data requesting transmission of an update date and time of setting information from the thin client terminal1through the reception control module22. The encryption/decryption module23and the client verification module24determine whether the terminal transmitting the second data is a thin client terminal1registered with the management server2, by using the thin client information29B and a production number included in the second data. That is, whether a terminal that has the production number included in the second data is a thin client terminal1registered with the management server2, is determined. The client verification module24notifies the control module21of a verification result as to whether the terminal transmitting the second data is a thin client terminal1registered with the management server2.

Specifically, the encryption/decryption module23and the client verification module24read a record from the thin client information29B. The encryption/decryption module23decrypts the received second data using a common key in the record. Then, the client verification module24determines that the terminal receiving the second data is a thin client terminal1registered with the management server2when a production number in the record and a production number in the decrypted second data match.

On the other hand, when a production number in the record and a production number in the decrypted second data do not match, a different record is read from the thin client information29B, and whether the terminal transmitting the second data is a thin client terminal1registered with the management server2is determined using the different record. Then, when the production numbers in all records in the thin client information29B do not match with the production number in the decrypted second data, the client verification module24determines that the terminal transmitting the second data is not a thin client terminal1registered with the management server2. In that case, the management server2discards the second data and does not respond to the terminal transmitting the second data at all, for example.

When a verification result notified by the client verification module24indicates that the terminal transmitting the second data is a thin client terminal1registered with the management server2, and when the decrypted second data includes a transmission request of a setting information update date and time, the control module21instructs the transmission data generation module251to generate third data. The third data includes an update date and time of setting information to be distributed to the thin client terminal1.

The transmission data generation module251acquires an update date and time from the record of the thin client information29B corresponding to the thin client terminal1, and generates third data including the acquired update date and time. The encryption/decryption module23encrypts the third data using a common key included in the record. The control module21transmits the encrypted third data to the thin client terminal1through the transmission control module27.

Then, the control module21receives fourth data for requesting transmission of setting information from the thin client terminal1through the reception control module22. The encryption/decryption module23and the client verification module24determine whether a terminal transmitting the fourth data is a thin client terminal1registered with the management server2, by using the thin client information29B and a production number included in the fourth data. That is, whether the terminal that has the production number included in the fourth data is a thin client terminal1registered with the management server2, is determined. The client verification module24notifies the control module21of a verification result as to whether the terminal transmitting the fourth data is a thin client terminal1registered with the management server2. Details of a verification method are similar to the above-described verification method performed when the second data is received.

When the verification result notified by the client verification module24indicates that the terminal transmitting the fourth data is a thin client terminal1registered with the management server2, and when the decrypted fourth data includes a transmission request of setting information, the control module21instructs the transmission data generation module251to generate fifth data. The fifth data includes setting information to be distributed to the thin client terminal1.

The transmission data generation module251generates fifth data including the setting information, by using a record in the thin client information29B corresponding to the thin client terminal1and a record in the group information29C corresponding to a group to which the thin client terminal1belongs. Specifically, the transmission data generation module251reads, for example, a first record corresponding to the production number of the thin client terminal1from the thin client information29B stored in the database29. Based on a group name included in the read first record, the transmission data generation module261reads a second record corresponding to the group name from the group information29C stored in the database29. The transmission data generation module251generates the fifth data including the setting information using the first and second records. Thus, the setting information transmitted to the thin client terminal1may include at least a part of data included in the first record of the thin client information29B and at least a part of data included in the second record of the group information29C.

FIG. 19shows a configuration example of the fifth data including setting information71transmitted from the management server2to a thin client terminal1. The fifth data is, for example, XML-format data.

As described above, the transmission data generation module251generates the setting information71, by using the first record of the thin client information29B corresponding to the thin client terminal1as a transmission destination and the second record of the group information29C corresponding to the group to which the thin client terminal1belongs. Thus, the setting information71includes information obtained from the first and second records.

Specifically, the setting information71includes first information obtained from the first record of the thin client information29B. The first information includes a computer name, and an identifier, a user certificate (including update date and time thereof), a private key (including update date and time thereof) and a private password that are related to LAN security setting. The setting information71further includes second information obtained from the second record of the group information29C. The second information includes a management server URL, a download server URL, a VDI server URL, a BIOS setting kitting file (including an update date and time thereof), and the number of retry, a retry interval, a polling interval, an action upon disconnection and a domain that are related to communication setting.

In the setting information71, the above-mentioned information is included in the following data formats.

(2) Identifier of LAN security setting: Text

(3-1) File name of user certificate of LAN security setting: Text

(3-2) Update date and time of user certificate of LAN security setting: Date

(3-3) Body of file of user certificate of LAN security setting: Base64

(4-1) File name of private key of LAN security setting: Text

(4-2) Update date and time of private key of LAN security setting: Date

(4-3) Body of file of private key of LAN security setting (that is, data of file): Base64

(5) Private password of LAN security setting: Text

(6) Management server URL: Text

(7) Download server URL: Text

(9-1) File name of BIOS setting kitting file: Text

(9-2) Update date and time of BIOS setting kitting file: Date

(10) Number of retry of communication setting: Text

(11) Retry interval of communication setting: Text

(12) Polling interval of communication setting: Text

(13) Action upon disconnection of communication setting: Text

(14) Domain of communication setting: Text

(15) Update date and time: Date

Note that Text format data includes one or more character codes. Date format data includes a value indicative of a date, or a value indicative of a date and time. Base64 format data includes one or more ASCII codes obtained by converting binary data of a file. These data formats above are examples, and may be changed to any formats capable of transmitting each data above.

FIG. 20shows a configuration example of BIOS setting kitting file72included in the setting information71. The BIOS setting kitting file72is used for BIOS setting of a thin client terminal1that belongs to a group associated with the BIOS setting kitting file72.

The BIOS setting kitting file72includes, for example, a language setting, a keyboard setting, a time zone, a priority band of wireless LAN (for example, Wi-Fi), an aggressiveness of wireless LAN roaming, a network mode, an SSID for priority connection of wireless LAN, an authentication method for priority connection of wireless LAN, a user name for priority connection of wireless LAN, and a password for priority connection of wireless LAN.

The language setting indicates a language used in the thin client terminal1. One language selected from, for example, Japanese, English, and German is set as the data. The thin client terminal1may display characters that are available in a mode of the set language, on the screen.

The keyboard setting indicates a language supported by a keyboard that is included in or connected to the thin client terminal1. One language selected from, for example, Japanese, English, and German is set as the data.

The time zone indicates a time zone of a location where the thin client terminal1is used. The time zone corresponds to a region having the same standard time. A name of country or city representing the region of a certain standard time (such as Asia/Tokyo, America/New York, or Europe/London) may be set as the data. Alternatively, a time differential from a coordinated universal time (UTC) of a certain region (for example, UTC+09:00, UTC−04:00, or the like) may be set as the data.

The priority band of wireless LAN indicates a frequency band of wireless LAN to which the thin client terminal1should be connected first. For example, one of “Non” indicative of no frequency band to be selected, “5.2 GHz” indicative of a frequency band of 5.2 GHz, and “2.4 GHz” indicative of a frequency band of 2.4 GHz is set as the priority band of wireless LAN.

The aggressiveness of wireless LAN roaming indicates an index of aggressiveness when the thin client terminal1performs roaming of wireless LAN. For example, one of “Low” indicative of a low aggressiveness, “Medium” indicative of a middle aggressiveness, and “High” indicative of a high aggressiveness is set as the data.

The network mode indicates a mode of network used by the thin client terminal1. For example, one of “Auto” indicative of automatic selection of a network to be connected, “Wired” indicative of a wired network, and “WiFi” indicative of a wireless network is set as the data.

The SSID for priority connection of wireless LAN indicates an SSID of an access point where the thin client terminal1is connected. A character string indicating the SSID is set as the data.

The authentication method for priority connection of wireless LAN indicates an authentication method used by the thin client terminal1for the wireless LAN connection. For example, one of the authentication methods of WEP and WPA-Enterprise (PEAP/TLS) is set as the authentication method for priority connection of wireless LAN.

The user name for priority connection of wireless LAN indicates a user name used by the thin client terminal1for the wireless LAN connection. A character string indicating the user name is set as the user name for priority connection of wireless LAN.

The password for priority connection of wireless LAN connection indicates a password used by the thin client terminal1for the wireless LAN connection. A character string indicating the password is set as the password for priority connection of wireless LAN.

With the BIOS setting kitting file72configured as above, various parameters used by BIOS of each thin client terminal1may be set or updated.

The above settings using the BIOS setting kitting file72may be managed by, instead of BIOS, an operating system (OS) such as Windows (registered trademark) in a conventional personal computer. As compared to an OS executed on the conventional personal computer, the OS executed on the thin client terminal1may have limited functions and may not have a function to manage the above settings. Thus, a function to manage the above settings using the BIOS setting kitting file72is provided with the BIOS on the thin client terminal1.

The transmission data generation module251generates fifth data including the setting information71with the configuration described above with reference toFIGS. 19 and 20. The encryption/decryption module23encrypts the fifth data using a common key included in a record of the thin client information29B corresponding to the thin client terminal1. Then, the control module21transmits the encrypted fifth data to the thin client terminal1through the transmission control module27.

Note that, the setting information71may include a file name of the BIOS setting kitting file72instead of the BIOS setting kitting file72itself. In that case, the thin client terminal1can download the BIOS setting kitting file72from the download site216of the management server2, by using the file name and a download server URL included in the setting information71.

With the above-described configuration, the management server2can distribute setting information71(to be newly set) to the proper thin client terminal1registered with the management server2, by using the thin client information29B and the group information29C that are updated in accordance with the operation by the manager using the management console5.

Now, a functional configuration of the thin client terminal1will be explained.

As shown inFIG. 14, the thin client terminal1includes an encryption/decryption module13, a network processing module14, an information storage area16, a transmission data generation module18, and a reception data analysis module19. The network processing module14includes a transmission control module141that transmits data to an external device such as the management server2, a reception control module142that receives data from the external device, and a reception wait timer143that waits the reception of data from the external device. The transmission control module141and the reception control module142communicate with the external device through a communication method based on HTTP or HTTPS, for example.

The information storage area16is, for example, a specific rewritable memory area in BIOS-ROM104. In the information storage area16, a production number161, a setting information update date and time162, and setting information163may be stored. The production number161is identification information that uniquely identifies the thin client terminal1. The setting information163includes various information related to the operation of the thin client terminal1.

After the thin client terminal1is subjected to the setup process, the setting information163includes, for example, one or more items of information (parameters) obtained by analyzing first data for setup received from the management server2and written. The setting information update date and time162indicates a date and time of when the management server2creates the first data for setup.

When the thin client terminal1is subjected to the setup process and then the setting information163is further updated, the setting information163includes, for example, at least one or more items of information obtained by analyzing updated data received from the management server2and written. The update date and time162indicates a date and time of when the management server2creates the updated data.

Hereinafter, operations of each component in the thin client terminal that has been subjected to the setup process will be exemplified. Note that, the same operations are performed when the thin client terminal1is subjected to the setup process and then the setting information163is further updated.

The thin client terminal1performs, in response to turning on thereof, a boot authentication process with the management server2. In the boot authentication process, the management server2determines whether a thin client terminal1is a proper thin client terminal. In the boot authentication process, as to a proper thin client terminal1, the setting information163stored in the information storage area16may be updated.

The network processing module14connects the thin client terminal1to a network in response to the turning on of the thin client terminal1. For example, the transmission control module141requests the DHCP server3to assign an IP address, and the reception control module142receives an IP address assigned by the DHCP server3. The network processing module14connects the thin client terminal1to the network using the received IP address.

The transmission data generation module18generates second data to request the management server2to transmit an update date and time of setting information in response to the turning on of the thin client terminal1. The second data includes, for example, a production number161read from the information storage area16and an acquisition request of the update date and time of the setting information.

The encryption/decryption module13encrypts the generated second data using a common key (with the management server2) included in the setting information163. The common key is, for example, received from the management server2in the setup. Furthermore, the encryption method may be, for example, AES256.

The transmission control module141transmits the encrypted second data to the management server2. The transmission control module141may start the reception wait timer143in response to this transmission. The reception wait timer143sets a first time to detect a timeout while the thin client terminal1waits for reception of third data transmitted from the management server2(that is, third data including an update date and time of setting information). When the reception wait timer143has detected a timeout while waiting for the reception of the third data, the thin client terminal1stops the update process of the setting information163and performs a normal boot process.

The reception control module142receives the third data including the update date and time of setting information from the management server2. The reception control module142may stop the reception wait timer143in response to this reception.

The encryption/decryption module13decrypts the third data. The encryption/decryption module13sends the decrypted third data to the reception data analysis module19.

The reception data analysis module19reads the setting information update date and time162from the information storage area16, and compares the read setting information update date and time162with the update date and time included in the decrypted third data. When the read setting information update date and time162differs from the update date and time included in the decrypted third data, the reception data analysis module19requests the transmission data generation module18to generate fourth data to request the management server2to transmit setting information.

The transmission data generation module18generates fourth data in accordance with the request by the reception data analysis module19. The fourth data includes, for example, the production number161read from the information storage area16and an acquisition request of setting information.

The encryption/decryption module13encrypts the generated fourth data using the common key with the management server2. The transmission control module141transmits the encrypted fourth data to the management server2. The transmission control module141may start the reception wait timer143in response to this transmission. The reception wait timer143sets a second time to detect a timeout while the thin client terminal1waits for reception of fifth data transmitted from the management server2(that is, fifth data including setting information). When the reception wait timer143has detected a timeout while waiting for the reception of the fifth data, the thin client terminal1stops the update process of the setting information163and performs a normal boot process.

The reception control module142receives the fifth data including the setting information71from the management server2. The reception control module142may stop the reception wait timer143in response to this reception.

The encryption/decryption module13decrypts the fifth data. The encryption/decryption module13sends the decrypted fifth data to the reception data analysis module19.

The reception data analysis module19analyzes the setting information71included in the decrypted fifth data, and acquires data corresponding to items. The reception data analysis module19updates the setting information163stored in the information storage area16using the acquired data. That is, the reception data analysis module19updates the setting information163by replacing data of an item in the stored setting information163with the acquired data of the item. The reception data analysis module19also updates the setting information update date and time162by replacing the update date and time in the setting information update date and time162with the update date and time included in the setting information71.

The setting information71in the decrypted fifth data may include a file. In that case, the reception data analysis module19updates the setting information163by analyzing the file. The file is, for example, a BIOS setting kitting file72. The reception data analysis module19updates data of BIOS setting included in the setting information163in the information storage area16, by using data obtained by analyzing the BIOS setting kitting file72included in the setting information71.

The thin client terminal1is rebooted in response to the update of the setting information163by the reception data analysis module19using the data of all items obtained from the decrypted fifth data. With this reboot, the thin client terminal1operates using the updated setting information163. That is, the updated setting information163can be reflected upon the operation of the thin client terminal1.

Through the above process, since setting information of each thin client terminal1and each group is distributed to each thin client terminal1managed by the management server2, the setting information changed in the management server2can be reflected upon the thin client terminal1. The manager can manage multiple thin client terminals1altogether using the management server2and the management console5. Thus, a workload required for the management can be reduced, and the security of the managed thin client terminal1can be improved.

Note that, the first data for setup transmitted from the management server2to the thin client terminal1may include the BIOS setting kitting file72. In that case, the setup of the thin client terminal1can be performed using the information obtained from the analysis of the BIOS setting kitting file72.

With reference to the flowchart ofFIG. 21, an example of the procedure of an update control process executed by the thin client terminal1will be explained.

Firstly, the thin client terminal1is connected to a network in response to turning on and starting boot thereof (step S61). The thin client terminal1is connected to the network using, for example, an IP address leased by the DHCP server3.

Then, the thin client terminal1executes an acquisition process of update date and time to acquire a date and time of when setting information of the thin client terminal1is updated in the management server2(step S62). The thin client terminal1executing the acquisition process of update date and time receives third data including the update date and time from the management server2. The acquisition process of update date and time will be explained later with reference toFIG. 22.

Then, the thin client terminal1reads the setting information update date and time162stored in the information storage area16(step S63). The thin client terminal1determines whether the update date and time in the third data matches with the read setting information update date and time162(step S64). When the update date and time in the third data matches with the read setting information update date and time162(YES in step S64), the thin client terminal1is booted normally since the setting information is not updated in the management server2and there is no need of updating the setting information in the thin client terminal1.

On the other hand, when the update date and time in the third data differs from the read setting information update date and time162(NO in step S64), the thin client terminal1executes an update process to update the setting information set to the thin client terminal1using the setting information distributed from the management server2(step S65) and is rebooted. The update process will be explained later with reference toFIG. 23.

FIG. 22shows a flowchart of an example of the procedure of the acquisition process of update date and time executed by the thin client terminal1. The acquisition process of update date and time corresponds to step S62described above with reference toFIG. 21.

Firstly, the thin client terminal1reads a production number161from the information storage area16, and generates second data including the production number161and the acquisition request of update date and time (step S621). The thin client terminal1encrypts the second data using a common key (step S622). The common key is included in, for example, the setting information163stored in the information storage area16.

The thin client terminal1starts the reception wait timer143(step S623) and transmits the encrypted second data to the management server2(step S624). The reception wait timer143sets a first time to detect a timeout while the thin client terminal1waits for reception of third data transmitted from the management server2.

Then, the thin client terminal1determines whether the third data has been received from the management server2(step S625). When the third data has not been received from the management server2(NO in step S625), the thin client terminal1determines whether the reception wait timer143has detected a timeout (step S628). That is, the thin client terminal1determines whether the time elapsed from the start of the reception wait timer143has exceeded the first time. When the reception wait timer143has not detected the timeout (NO in step S628), the process returns to step S625.

When the reception wait timer143has detected the timeout (YES in step S628), the thin client terminal1is booted normally. Note that, if the update control process including the acquisition process of update date and time is performed during the boot authentication of the thin client terminal1, the timeout of the reception wait timer143indicates that the management server2does not respond to the thin client terminal normally. Thus, the thin client terminal1that transitions to the normal boot state may be turned off.

On the other hand, when the third data has been received from the management server2(YES in step S625), the thin client terminal1stops the reception wait timer143(step S626) and decrypts the third data using a common key (step S627). Thus, the update date and time of the setting information included in the decrypted third data can be acquired.

FIG. 23shows a flowchart of an example of the procedure of the update process executed by the thin client terminal1. The update process corresponds to step S65described above with reference toFIG. 21.

Firstly, the thin client terminal1reads a production number161from the information storage area16, and generates fourth data including the production number161and an acquisition request of setting information (step S651). The production number161may be temporarily stored in the main memory103. The thin client terminal1encrypts the fourth data using a common key (step S652).

The thin client terminal1starts the reception wait timer143(step S653) and transmits the encrypted fourth data to the management server2(step S654). The reception wait timer143sets a second time to detect a timeout while the thin client terminal1waits for reception of fifth data transmitted from the management server2.

Then, the thin client terminal1determines whether the fifth data has been received from the management server2(step S655). When the fifth data has not been received from the management server2(NO in step S655), the thin client terminal1determines whether the reception wait timer143has detected a timeout (step S659). That is, the thin client terminal1determines whether the time elapsed from the start of the reception wait timer143has exceeded the second time. When the reception wait timer143has not detected the timeout (NO in step S659), the process returns to step S655.

When the reception wait timer143has detected the timeout (YES in step S659), the thin client terminal1is booted normally. Note that, if the update control process including the acquisition process of update date and time is performed during the boot authentication of the thin client terminal1, a timeout of the reception wait timer143indicates that the management server2does not respond to the thin client terminal1normally. Thus, the thin client terminal1that transitions to the normal boot state may be turned off.

On the other hand, when the fifth data has been received from the management server2(YES in step S655), the thin client terminal1stops the reception wait timer143(step S656) and decrypts the fifth data using the common key (step S657). Then, the thin client terminal1updates the setting information163and the setting information update date and time162in the information storage area16with the setting information71obtained by analyzing the decrypted fifth data (step S658). The contents of the decrypted fifth data, that is, the contents of the setting information71is described above with reference toFIG. 19. The thin client terminal1updates the setting information update date and time162in the information storage area16with the update date and time in the setting information71, and updates the setting information163in the information storage area16with other items in the setting information71.

Note that, when data of an item in the setting information163in the information storage area16and data in the setting information71corresponding to the item are the same (that is, the data has not been updated), the data of the item in the setting information163may not be updated. Furthermore, when data of an item in the setting information163is a file, a file name or a file update date and time of the file is compared to a file name or a file update date and time of a file in the setting information71corresponding to the item. When they are different, the file of the item in the setting information163is updated with the file of setting information71. The file may be, for example, a file of a user certificate of LAN security setting, a file of a private key of LAN security setting, or the BIOS setting kitting file72.

Furthermore, the setting information71may include, instead of data of a file, a file name and a file update date and time of the file. In that case, a file name or a file update date and time of a file included in the setting information163is compared to a file name or a file update date and time of a corresponding file in the setting information71. When they are different, the thin client terminal1downloads the file for update having the file name indicated in the setting information71from the download site216of the management server2. Then, the thin client terminal1updates the file in the setting information163with the downloaded file.

Through the above process, when updated setting information71is present in the management server2, the updated setting information71can be distributed to and reflected upon the authenticated thin client terminal1.

An example of a response process executed by the management server2will be explained with reference toFIG. 24.

Firstly, the management server2determines whether data has been received (step S71). When the data has not been received (NO in step S71), the process returns to step S71.

On the other hand, when the data has been received (YES in step S71), the management server2reads a record from the thin client information29B (step S72). The management server2decrypts the reception data using a common key included in the record (step S73). Then, the management server2determines whether a production number included in the decrypted reception data and a production number included in the record match (step S74). That is, whether the terminal transmitting the data to the management server2is a thin client terminal1registered with the management server2, is determined.

When the production number in the decrypted reception data is different from the production number in the record (NO in step S74), the management server2determines whether the thin client information29B includes another record that has not been read yet (step S75). When the thin client information29B includes another record (YES in step S75), the process returns to step S72, and whether the terminal transmitting the data to the management server2is a thin client terminal1registered with the management server2is determined using the another record.

On the other hand, when the thin client information29B does not include any record to be processed (NO in step S75), the process returns to step S71. That is, the management server2determines that the terminal transmitting the data to the management server2is a terminal unregistered with the management server2.

When the production number in the decrypted reception data and the production number in the record match (YES in step S74), that is, when the terminal transmitting the data is a thin client terminal1registered with the management server2, the management server2determines whether the decrypted reception data includes an acquisition request of update date and time (step S76). When the decrypted reception data includes the acquisition request of update date and time (YES in step S76), the management server2executes a transmission process of update date and time to transmit the update date and time of when the management server2updates the setting information to be transmitted to the thin client terminal1, to the thin client terminal1(step S77). The transmission process of update date and time will be explained later with reference toFIG. 25.

On the other hand, when the decrypted reception data does not include the acquisition request of update date and time (NO in step S76), the management server2determines whether the decrypted reception data includes an acquisition request of setting information (step S78). When the decrypted reception data includes the acquisition request of setting information (YES in step S78), the management server2executes a transmission process of setting information to transmit the setting information to the thin client terminal1(step S79). The transmission process of setting information will be explained later with reference toFIG. 26.

FIG. 25shows a flowchart of an example of the procedure of the transmission process of update date and time executed by the management server2. In the transmission process of update date and time, in accordance with a request by a thin client terminal1registered with the management server2, the update date and time of setting information71to be distributed to the thin client terminal1is transmitted to the thin client terminal1. The transmission process of update date and time corresponds to step S77described above with reference toFIG. 24.

The management server2acquires an update date and time corresponding to the production number of the thin client terminal1(step S771). The update date and time may be acquired from the thin client information29B in the database29, or may be acquired from the record of the thin client information29B read to determine whether the thin client terminal1is a terminal registered with the management server2(that is, the record read in step S72ofFIG. 24).

The management server2generates third data including the acquired update date and time (step S772). The management server2encrypts the third data using a common key (step S773). Then, the management server2transmits the encrypted third data to the thin client terminal1(step S774).

As described above, the management server2can transmit to the thin client terminal1, the update date and time of the setting information71updated by the management server2and to be distributed to the thin client terminal1.

FIG. 26shows a flowchart of an example of the procedure of the transmission process of setting information executed by the management server2. In the transmission process of setting information, in accordance with a request by a thin client terminal1registered with the management server2, the setting information is distributed to the thin client terminal1. The transmission process of setting information corresponds to step S79described above with reference toFIG. 24.

Firstly, the management server2acquires the setting information71from the database29, based on the production number of the thin client terminal1(step S791). The management server2reads, for example, a first record corresponding to the production number of the thin client terminal1from the thin client information29B stored in the database29. Based on a group name included in the first record, the management server2reads a second record from the group information29C stored in the database29. The management server2generates the setting information71using the first and second records.

The management server2generates fifth data including the acquired setting information71(step S792). The management server2encrypts the fifth data using a common key (step S793). Then, the management server2transmits the encrypted fifth data to the thin client terminal1(step S794).

As described above, the management server2can transmit the setting information71to the thin client terminal1.

As can be understood from the above, according to the present embodiment, setting information can easily be updated. A thin client terminal1stores setting information163and a setting information update date and time162that are included in first data transmitted from a management server2, into an information storage area16. The setting information update date and time indicates a first date and time of when the management server2generates the setting information163. The first data is, for example, data for setup. When the thin client terminal1is booted after the setting information163and the setting information update date and time162are stored into the information storage area16, the thin client terminal1transmits second data to the management server2. The second data includes a transmission request of a second date and time of when the management server2updates the setting information. When the second data is received from the thin client terminal1, the management server2transmits third data including the second date and time to the thin client terminal1.

Then, the thin client terminal1receives the third data from the management server2. When the second date and time included in the third data is different from the first date and time indicated by the setting information update date and time162, the thin client terminal1transmits fourth data including a transmission request of updated setting information to the management server2. When the fourth data is received from the thin client terminal1, the management server2transmits fifth data including updated setting information163to the thin client terminal1.

The thin client terminal1receives the fifth data from the management server2, updates the setting information163stored in the information storage area16with the updated setting information included in the fifth data, and updates the setting information update date and time162stored in the information storage area16with the second date and time. Thus, a manager can easily update the setting information163set to the authenticated thin client terminal1.

Various functions of the above embodiments may be realized by a circuit (process circuit). Examples of the process circuit include a programmed processor such as a central processing unit (CPU). The processor executes each of the functions described above by executing a computer program (instructions) stored in a memory. The processor may be a microprocessor including electric circuits. The examples of the process circuit also include a digital signal processor (DSP), an application specific integrated circuit (ASIC), a microcontroller, a controller, and other electric circuit components. Each component other than the CPU described in the above embodiments may be realized by the process circuit.

Since the processing of the embodiments can be implemented by a computer program, advantages similar to the advantages of the embodiments can easily be obtained by installing the computer program into a computer via a computer-readable storage medium in which the computer program is stored and by merely executing the computer program.