WO2002073438A1

WO2002073438A1 - Method and system for management of remote devices

Info

Publication number: WO2002073438A1
Application number: PCT/US2002/007511
Authority: WO
Inventors: Carl Hughey; Carlos Ojeda; Kelly Noordam; Timothy Bendel
Original assignee: Izorch Systems
Priority date: 2001-03-13
Filing date: 2002-03-13
Publication date: 2002-09-19

Abstract

A method and system for providing and managing services such as, television, personal computing and interactive services, from a central location (106, Fig. 2) to remote locations includes a remote device, for example a personal computer (PC) (101, Fig. 2) which is provided one of the remote locations. A user at the remote location uses the remote device to select services they desire, for example web-browsing. The selected services can also be provided to the user via the remote device. The remote device is managed from the central location. In such a manner, the method and system facilitates management and state-maintenance of remote devices in a number of different states and associated transitions between states of remote devices ranging from bare-metal installation to fully operational application-specific states with the ability to identify, alert/notify and provide remediation of problems. Additionally, pre-execution and post-execution code image manipulation and distribution with pre-boot rules-based state management can be provided.

Description

METHOD AND SYSTEM FOR MANAGEMENT OF REMOTE DEVICES

Field of the Invention The present invention relates to a method and system for managing and providing services from a central location to remote locations and in particular to providing and managing television, personal computer and interactive services to hotels and multiple dwelling units.

Background of the Invention

In the hotel business, maximizing guest satisfaction is a priority. Any customer dissatisfaction or guest frustration can cause complaints which ultimately result in a loss of revenue. One area in which a hotel guest expects a high standard of performance is in the proper functioning of entertainment equipment provided in the guest room. In recent years, the use of hotel entertainment systems to provide in-room entertainment and services has become increasingly widespread. Such entertainment systems often include hotel television, pay-per-view movie systems, in-room video games and, more recently, computing services and internet access. These systems are both a source of entertainment for the guest and a means to collect revenue for the hotelier. Such systems also often allow the guest to order hotel services such as laundry services and room service, and can provide alternative folio review and checkout services.

Such entertainment systems are currently provided through a variety of different components. The different components are located in the guest's room. These entertainment systems usually must include a method for identifying guest selections and tracking use of the different components for billing purposes. One such method of billing includes the use of a unique address which associates a unique address with the components in each hotel guest's room. Typically, the address is located in the component. When a hotel guest watches a pay- per-view movie on the television, for example, the cost of the movie is charged to the unique address. When the hotel guest checks out of the hotel, the guest pays for all pay-per-view movies billed to that unique address.

Typically, when a hotel guest is paying his or her bill, the guest is in a hurry to check out and leave the hotel. Tracking the use of all the different components of the entertainment system can be quite difficult. Great dissatisfaction occurs if the hotel guest is improperly billed. Moreover, improper billing may result in a loss of revenue to the hotel due to the loss of repeat business from an unhappy hotel guest or loss of revenue due to improper billing.

Accordingly, there is a need for a system and method that can manage devices at remote locations, such as hotel rooms. Additionally, one device that can provide a variety of functions and reduce problems with tracking the use of the different components is also necessary.

Summary of the Invention

A method and system for providing and managing services such as, television, personal computing and interactive services, from a central location to remote locations is provided. A remote device, for example a personal computer (PC) may be provided at the remote location. A user at the remote location can use the remote device to select services they desire, for example web-browsing. The selected services can be provided to the user via the remote device. The remote device can be managed from a central location. In an exemplary embodiment, the present invention may enable the management and state-maintenance of remote devices in a number of different states and associated transitions between states of remote devices ranging from bare-metal pre-installation to fully operational application- specific states with the ability to identify, alert/notify and provide remediation of problems. Additionally, pre-execution and post-execution code image manipulation and distribution with pre-boot rules-based state management can be provided.

According to a further embodiment, a computer useable information storage medium storing computer readable program code can be provided. This embodiment may include executable code and associated logic for controlling bootable states of a hardware device with discrete state logic, rules-based transitional state logic and control functionality. Hardware device state maintenance and management with remote alerting and notification capability including granular hardware device failure detection and unauthorized hardware/software device usage disabling functionality may also be provided.

According to another embodiment of the invention, a method and system for providing a plurality of services to a user at a remote location through one device at the remote location. Entertainment and personal productivity/generic computing functionality can be delivered through a single multi-service convergence device. The multi-convergence device may be provided with automated personalization and customization based upon integration with a property management system for a hotel or multiple dwelling unit, for example. The method and system can support video-on-demand (NOD), near-VOD, with simultaneous display of video on both television and a computer monitor, concurrent usage of both VOD and personal computing applications as well as gaming, web browsing, DVD/music CD playback, MP3 playback, voice over IP capability (internet telephony) and cable TV tuner functionality with integrated dynamic menu system display via both computer monitor and television.

Hospitality guest services functionality for hotels and the like may be provided through personal computer-based guest check-in/check-out, guest folio review, folio charge posting and real-time guest folio validation functionality, guest personal computer alarm clock functionality with customization for wake-up state and content display configuration. According to a further embodiment, a computer useable information storage medium storing computer readable program code can be provided. This embodiment may include executable code and associated logic for controlling dynamic hardware device configuration and customization through interface definitions and mappings to property management systems. Functionality that supports programmatic bi-directional interface for discrete state management of hardware/software devices may be provided. This functionality may include programmatic extensions for strongly validated demographic usage-based data-driven profiling.

Brief Description of the Drawings FIG. 1 is a diagram of a multi-dwelling unit having remote devices connected to a central location;

FIG. 2 is a schematic diagram of a system that can provide remote management capability according to the invention; and

FIG. 3 is a logical component model of one embodiment of the invention.

Detailed Description of the Invention

A method and system for managing remote devices is provided. The system and method may provide entertainment and computing functionality to the remote device. The remote device may be amulti-service convergence device that allows concurrent video-on- demand and computing services. The system should be able to manage and control a number of remote devices from a central location. For example, the remote device may be a PC provided with high functionality that can be turned on and off depending on the situation. In order for functionality to be enabled, the PC should communicate with a central server via, for example, the Internet.

The method and system can provide a subscription personal computing service with remote management capability. The service and management system are particularly well suited for application in the Hotel and Multiple Dwelling Unit industry and is described below in that context. However, the service and system can easily be applied in other operation venues. Moreover, the principles described below may also be applied to management and use of servers on a subscription basis.

As is well known, a hotel includes a number of rooms where guests reside during their stay. FIG. 1 illustrates a number of rooms provided with remote devices, for example, a PC. The PC should be a "dumb" terminal; that is, the PC should not be able to be booted up or used without proper authorization. The authorization, operating system, and other software may be provided from the central server to the PC. Each of the rooms contains a jack that leads to a connection to a central location, for example, a central wiring closet containing the property server. The PC terminal is connected to a network through the jack and thus to the local property network and thus, the property server. Authorization to boot the PC is provided from the property server to the in-room PC device programmatically through the device management software. Alternatively, the jacks may be provided in a conference room or the like. Thus, the remote devices can be installed and utilized for use at conferences and other functions a hotel may host in any public or private space. In a preferred embodiment, the hotel's management system is also connected to the property server. Before a PC can be enabled, information will be extracted programmatically from the hotel's property management system to the property server. For example, the hotel may send information to the property server that a particular room number has been issued a PC and a guest has checked into that room. In response to this information from the hotel, the property server enables the in-room PC device, customizes the environment for the hotel guest through a stored profile application and powers the PC device up prior to the guest entering the hotel room. The property server preferably has complete state control of remote systems including power-on, power-off, reboot, image loading, software patching, BIOS upgrades, CMOS setting changes, etc. of the PC terminal. Additionally, the property server may handle installation of software on the remote PC terminal (including the operating system). This can be done, for example, based on Intel's Preboot-eXecution Environment (PXE) utilizing compressed system images and a network distribution scheme. The user of a remote device can select access to particular software programs, such as word-processing programs, as well as Internet access. A hotel guest may store files and operating system desktop configuration setting along with application-specific data at an ephemeral network storage location so that the files may be available via the network and integrated into the user interface of the in-room PC device when the guest arrives at the hotel or wherever they travel and the network system and property server or the management system is available. Guests' can therefore travel without carrying bulky laptops or even floppy disks, which can easily be lost or misplaced. All hardware, software, and files maybe provided via the system. Moreover, the system allows for individual and group customizations of systems. Secure identification and encryption methods can be used to ensure the protection of data at the property server and the network storage locations. Strong authentication and encryption should be used for all aspects of operation of the system, including remote command/control and software installation.

In addition to those described above, the management system can provide an additional variety of functionality and services. For example, a task scheduler can be provided that allows actions to be performed at a specific time of day. Optionally, the system can be integrated with existing on-site property management system for precise scheduling of events (refresh on customer checkout, etc.) Remote devices can be monitored to track detailed logging, SNMP trap generation (user power-off, reboot, startup, screen saver activation, etc.), e-mail notification, file transfer, and remote view/control capabilities. Automated IP address/DNS/Room number/asset number/image version management and integration for logging and error reporting can be provided. Local system caching of complete system images may be provided to reduce network bandwidth requirements and decrease image restoration times.

Additionally, during installation of remote devices, automatic PC platform detection may be provided. This requires less input from the system installer and allows multiple PC platforms to be used within a single site. A modular design is preferably used to allow rapid porting to different manufactures PC platforms.

In a preferred embodiment the method and system are preferably implemented in a computer network environment and are described below in a preferred embodiment in that context. Of course, the invention can be used in other environments. In one embodiment, the method and system may be implemented as a software application. The software application may execute on application servers provided in a typical three-tiered architecture. Figure 2 is a schematic diagram of a system 100 that can provide a management system for remote devices.

System 100 is adapted to be accessed by a plurality of clients 101, such as the remote devices and/or the hotel management system. Such clients 101, in turn, suitably comprise one or more conventional personal computers or intelligent devices. It should be understood, nevertheless, that other clients 101 such as Web-enabled hand-held devices (e.g., the Palm V™ organizer manufactured by Palm, Inc., Santa Clara, California U.S.A., Windows CE devices, and "smart" phones) which use the wireless access protocol, and Internet appliances fall within the spirit and scope of the present invention.

Clients 101 of all of the above types suitably access system 100 by way of the Internet 102. By use of the term "Internet", it should be understood that the foregoing is not intended to limit the present invention to a network also known as the World Wide Web. It includes intranets, extranets, Virtual Private Networks (VPNs), and the like. In any case, a pair of Internet access lines 103 (e.g., primary and shadow conventional T3 lines) is cross connected from the Internet 102 backbone to one or more, and preferably, a pair of redundant routers 104. Incoming traffic from the first of such routers 104 is then suitably directed through a firewall 105 to the second of such routers 104. Even more preferably, and for the sake of redundancy, two firewalls 105 are cross connected as shown in Fig. 2. A presently preferred router 104 is the SmartSwitch Router 8000, which is manufactured by the Enterasys Networks division of Cabletron Systems, Andover, Massachusetts U.S.A. Moreover, a presently preferred firewall 105 is an IP network application platform (e.g., the IP650, IP440, or IP330 firewall platforms, which are manufactured by Nokia Group, Espoo, Finland).

A plurality of web servers 106ι, 106₂, ... 106_n is, thus, conveniently load balanced by use of the foregoing configuration. That is, the load of incoming traffic from the Internet 102, through the routers 104 and firewalls 105, is balanced among each of the web servers 106ι, 106₂, ... 106_n, such that: (1) certain incoming traffic is routed to a particular web server 106], 106₂, ... 106_n, where that particular web server 106ι, 106₂, ... 106_n had been recently used by a given user whose information had been cached on that particular web server 106ι, 106 , ... 106_n and, as a result, it would be more efficient to continue to use that particular web server 106], 106₂, ... 106_n, or (2) no single one of the web servers 106j, 106₂, ... 106_n would become overburdened.

In a preferred embodiment of the present invention, there are several such web servers. Each of the web servers 106ι, 106₂, ... 106_n is, in turn, preferably comprised of a Dell™ PowerEdge™ 2450 server (manufactured by Dell Computer Corporation, Austin, Texas U.S.A.), with a 733MHz Pentium III processor, 256MB RAM, and dual, mirrored 9.1GB fixed disk drives. Preferably, each of the web servers 106ι, 106₂, ... 106_n further comprises a Microsoft® Windows® NT operating system, and Netscape Enterprise Server, Release 3.6.3 (developed by Netscape Communications, a subsidiary of America Online, Inc., Dulles, Virginia U.S.A.). Optionally, Netscape's Certificate Server may also be installed on each of the web servers 106], 106₂, ... 106_n to facilitate core digital certificate-issuance and management services, as well as distribution of certificates and certificate-revocation lists to clients and other servers. Other forms of certificate servers (e.g., web certificate servers and wireless certificate servers, which are available from VeriSign, Inc., Mountain View, California U.S.A.) may likewise be deployed on each of the web servers 106ι, 106₂, ... 106_n. System 100 further comprises a plurality of application servers 107ι, 107₂, ... 107_n, coupled to the web servers 106ι, 106 , ... 106_n. In the preferred embodiment of the present invention, there are several such application servers. Each of the application servers 107ι, 107₂, ... 107_n is, like the web servers 106ι, 106₂, ... 106_n, preferably comprised of a Dell PowerEdge 2450 server, with a 733MHz Pentium III processor, 256MB RAM, and dual, mirrored 9.1GB fixed disk drives. Preferably, each of the application servers 107], 107₂, ... 107_n further comprises a Microsoft Windows NT operating system. At the same time, a load balancer is loaded on each of the web servers 106ι, 106₂, ... 106_n, to facilitate balancing of the load of communications between each of the web servers 106ι, 106₂, ... 106_n and each of the application servers 107ι, 107 , ... 107_n.

Beneath the layer of web servers 106ι, 106₂, ... 106_n and application servers 107ι, 107₂, ... 107_n is a storage area network (SAN) 108. SAN 108 generally comprises a cluster server 109 that is connected to receive incoming Internet traffic through each of the application servers 107ι, 107₂, ... 107_n, and to transmit outgoing Internet traffic through the routers 104 and firewall 105, from the SAN 108 by way of either a file server 110 or a database server 111.

As seen in Fig. 2, the hardware comprising system 100 is substantially completed with the addition of high-availability storage 112 cross-connected to the file server 110 and database server 111. One suitable such high-availability storage 112 comprises the fiber channel switches 113, a pair of disk controllers 114, and a pair of disk arrays 115. Each of the disk controllers 114 preferably comprises a SCSI controller (e.g., a Symbios® SYM53C1010 UltralόO SCSI controller, manufactured by LSI Logic Corporation, Milpitas, California U.S.A.). In a presently preferred embodiment, the disk arrays 115 each comprise twenty 36GB LVD (i.e., low voltage differential) disk drives which are configured to be mirrored RAID 5. Suitable such LVD drives are, for example, the Ultrastar 36ZX hard disk drives manufactured by IBM Corporation, Armonk, New York U.S.A.

System 100 further comprises a tape library 116, which includes a plurality of advanced intelligent tape drives 117 (preferably AIT2 tape drives) and a plurality storage positions 118 for the AIT2 tapes. In a presently preferred embodiment, the tape library 116 comprises a TLS-4000 automated tape library (manufactured by Qualstar Corporation, Canoga Park, California U.S.A.), which can incorporate up to 12 AIT2 tape drives and has storage for at least 60 AIT2 tapes. Such tape library 116 furthermore preferably comprises suitable software (e.g., Veritas Netbackup™) to control reading and writing of data to the tape library 116.

A software process that takes receipt of HTTP requests preferably runs on web servers, 106ι, 106₂, ... 106_n. The web servers 106ι, 106₂, ... 106_n either handle the requests or forward them to other software/systems for handling. The software application preferably runs on the application servers 107ι, 107₂, ... 107_n behind the web-servers. The web servers forward appropriate requests to the application servers for processing. Responses to such requests are generated by the application servers and are passed back through the web server to the requesting client. The general manner in which this process occurs is well-known to one skilled in the art and is not described in more detail here. As mentioned above, the present invention may be implemented as software applications running on the client, the server, or both the client and server. FIG. 3 illustrates an example of a logical component model that can provide the management system according to the present invention. Initially, a number of remote devices (clients) are installed at a remote location, such as a hotel. The remote devices are to be managed and controlled from the central server. Therefore, the central server should be able to identify the remote device and it location, for example, by serial number of the device and the hotel and number of the room in which the device is located. The identification of remote devices is preferably performed when the devices are installed in the system. After the remote devices are installed, they can be accessed by hotel guests to obtain services. Generally, a guest at a hotel desires to access a service, such as web-browsing, movie viewing, etc., in their room. The guest can use the remote device to view the various services available and select the service they desire. The remote device communicates this selection to the property server. This communication preferably takes place over the hotel local area network or the Internet. Upon receipt of the communication from the remote device, the property server process the request and may enable the remote device to provide the service or may provide the requested service over the Internet, for example as an application service provider. Certain services may require interaction of a management station, i.e. the hotel management system, which can also be connected to the property server. For example, if no guest is registered as staying in a room, the remote device may be disabled until a guest checks-in to that room.

Components that may be included in a preferred embodiment of a software program and shown in FIG. 3 will now be described individually in more detail.

PC Manager

PC Manager (PCMGR) is the central program that initiates and maintains most operations within the system. PCMGR can coordinate system state changes and provide system logging. PCMGR should reside on the central server and may be called from other programs using a command line interface. Other programs such as the web management console use this interface to interact with the system. PCMGR may also directly interact with, among other components, Rembo, SSH/SCP, mySQL, PCM-DHCP, and PCM Agent (PCMA) on the client PCs. PCMGR is a module preferably written in perl using perl interpreter 5.x or C and should provide all or part of the functionality described in this section. Typically, when a device is connected to a network, it is assigned a MAC (Media Access Control) address. The MAC address is the device's unique hardware number. When the device is connected to the Internet, a correspondence table relates the IP address of the computer to the computer's physical (MAC) address on the network. The MAC address is used by the Media Access Control sublayer of the Data-Link Layer (DLC) layer of telecommunication protocol. There is a different MAC sublayer for each physical device type.

In the present case, to be able to locate a remote device, an administrator should enter the MAC address of the device that is added to the network. This may be done at the time of installation of a device or beforehand if the MAC address of the device is available before installation. When the MAC address for a particular device, such as a PC, boots up, the PC contacts the PCM-DHCP server for an address. The PCM-DHCP server, described below, spawns an instance of PCMGR to manage the installation process, including IP address assignment, DNS configuration, image loading and patching, device discovery, and database updates for serial number, room number, etc.

Due to potential conflicts with other DHCP servers that may be present in the hotel's systems, or unknown DHCP aware devices, the PCM-DHCP server normally uses fixed reservations for all IP/MAC combinations. However, during the installation of new properties or locations to the system, numerous remote devices need to be installed literally at once. Also, there are generally no other systems to contend with at the time of initial site installation. This option allows large numbers of devices to be installed nearly simultaneously and automatically by putting the PCM-DHCP server into promiscuous mode (replies to all requests) and enabling multicast transfers of images. This allows new devices to be installed quickly by automatically getting an IP address during boot up and to install a copy of the system image that is being multicast from the server. The PCs that are being installed coordinate their image download and will later request from the property server any portions of the image that were missed during the multicast. Once all systems have been deployed, the PCM-DHCP server is taken out of promiscuous mode and temporary leases are converted into permanent reservations. Also at this point all configuration information gathered (e.g., serial numbers, room numbers, IP addresses, DNS names, etc.) may be entered into the appropriate files and databases.

In addition to initially installing the remote devices, the system may manage a remote user's access to and use of the remote device. For example, when a guest checks-out of a room, device can be shut down and disabled. This option is normally called from the hotel management system and can be integrated with the check-out procedure. A "restore" operation is normally performed between a check-out of one hotel guest and the next check-in of a different guest using that same device. This operation may have a PC reformat and reload its primary partition, for example, Windows 2000 using a cached image of the device installed during a previous operation. It should be noted that since the image normally resides in a special cache partition on the local PC, very little network traffic is generated during this process and this process can be performed repeatedly on multiple systems with no network performance degradation. As mentioned above, this operation will normally restore the system from local cached file copies, however, if the master images have changed on the server, these images should be downloaded again and the new images should be cached. If a guest is checking-out of a room, the remote device may be powered off after imaging operations are complete. In addition, if the system is powered on before a subsequent check- in operation, described below, is performed, the PCMA process, also described below, on the remote device should send a trap and turn the remote device back off.

A check-in operation may also be called from and incorporated with the hotel management system. This operation can remove a state variable created during checkout, allowing the remote device to come up fully and a "wake" function can be called. The wake function sends a packet to the remote device causing its NIC hardware to power-on the system. This wake function is normally called from the web management interface. Accordingly, when a guest checks into a room, the device may be powered up and ready for them when they arrive in the room.

If a site is reducing PC count, for example, either by removing a device or by redeploying to another site, a PC can be removed completely from the system, including IP addressing, serial numbers, etc. If the PC is powered on with no definition in the system (assuming that the system is not in install mode), it will fail to get an IP address and will not boot. In instances of hard drive failure, the "FULL" option, described below, should be used. The system may also allow for the management and control of accessories attached to the PC, for example, a network-attached printer and associated queue. An administrator may add these to the system. Given a MAC address, this function may assign an IP address and auto-generate a new printer name using the format "PRTxxx", where xxx is the printer number. A spool directory should also be set up for the new printer. Once a printer has been added with this function, the printer should be turned on or reset to allow it to configure its networking parameters.

Once a printer/queue has been added, the parameter may be further configured using the PCMGR. This function can be used to disable unwanted protocols (e.g., IPX, DLC, AppleTalk, etc.) and to configure a password.

The ability to change PC print queue mapping may also be provided. In the case where multiple queues are available, this function allows an administrator to redirect print jobs for a particular PC to another queue. This re-mapping is preferably handled immediately via PCMA at the remote PC so a reboot is not necessary. The printer mapping status is saved so after subsequent refresh/reload cycles, the PC will retain the administrator applied print queue mapping. Additionally, the print device designation for a print queue may be changed. Say for instance that two printers are provided at a remote location and one of them will be offline for a few days for maintenance. Instead of changing the print queue mapping for all affected PCs, the device designation for their common queue may be temporarily changed to the working printer. Also, a print queue can be removed.

PCMGR can also provide other functions to control to remote device, such as the ability to move a device from one room to another within a property, sending a power-off command to a specified device, and allowing an administrator to remotely view the screen of a PC. To allow an administrator to view the screen, commands may be sent to the remote PCMA on the PC to temporarily enable the WinVNC service, described below. A Java based applet can be provided to allow viewing over SSH within the browser.

Furthermore, using a central server to manage remote devices may allow for tasks to be batched and executed at a specific time. For example, at 1 pm most hotels are within their standard window between normal check-ins and check-outs. Refresh/reload of remote devices can be performed at the same time each day using a sweep operation. During sweep operations, multicast transfers are used. Using a "refresh all" or "reload all" command, new system images can be pushed rapidly to all PCs during maintenance windows. Provisions may be made so that a command can be overridden (e.g., an early check-in has occurred) and executed immediately. This option could be easily expanded to schedule other events as needed for a specific application of the system.

PCMGR may also perform more drastic operations to the remote device. A "Full" operation may be provided that does a destructive repartition and format of the PC hard drive, downloads the required images to a cache partition, and restores these images. Image transfer across the network is preferably done via unicast to help reduce multicast/broadcast traffic on a potentially active network. This option is network intensive and is primarily to be used during instances of PC hard drive failure. This option does not prompt for room number or collect serial number information, therefore it should not be used during situations where a new PC is being added to the system or where a component other than hard drive (i.e., motherboard) has been replaced.

A "reload" operation may also be provided. It can optionally perform a FULL operation on a host immediately, schedule a FULL operation for the next SWEEP cycle, or schedule all hosts in the system for reload during the next sweep cycle.

Additionally, a BIOS option may be provided that allows a single PC to have its BIOS flashed/CMOS setup changed remotely. This function is normally performed during initial install into the system, but is provided to upgrade the BIOS on a single system after installation. PCMGR DISK

The PCMGR process and its associated modules normally run from within a RAM filesystem. However, it may be necessary to provide persistent storage (across boots) for items such as run queues and configuration files or to store large image files, which would not otherwise fit into memory. A PCMGR disk can be provided for this purpose. The disk may be disk 112 shown in FIG. 2 PCM-DHCP

The PCM-DHCP server may provide IP address, DNS server, default gateway, and other network information to remote devices during boot-up. Briefly, DHCP (Dynamic Host Configuration Protocol) is a protocol that lets network administrators manage centrally and automate the assignment of Internet Protocol (IP) addresses in an organization's network. Using the Internet's set of protocol (TCP/IP), each machine that can connect to the Internet needs a unique IP address. When an organization sets up its computer users with a connection to the Internet, an IP address must be assigned to each machine. Without DHCP, the IP address must be entered manually at each computer and, if computers move to another location in another part of the network, a new IP address must be entered. DHCP lets a network administrator supervise and distribute IP addresses from a central point and automatically sends a new IP address when a computer is plugged into a different place in the network.

DHCP uses the concept of a "lease" or amount of time that a given IP address will be valid for a computer. The lease time can vary depending on how long a user is likely to require the Internet connection at a particular location. It's especially useful in education and other environments where users change frequently. Using very short leases, DHCP can dynamically reconfigure networks in which there are more computers than there are available IP addresses. DHCP also supports static addresses for computers containing Web servers that need a permanent IP address.

The PCM-DHCP server may based upon the ISC 2.x DHCPD "C" source code. The areas of functionality specific to the system that may be added to the ISC 2.x DHCP source code include:

• Allow file - This is a file that lists MAC addresses that are allowed to get an IP address from this server (regardless if a fixed reservation exists or not). If the file exists, but no addresses are listed, NO system will be able to access the DHCP server. • Deny file - This is a file that lists MAC addresses that are NOT allowed to get an

IP address from this server (regardless if a fixed reservation exists or not). If the file exists, but no addresses are listed, ALL systems will be able to access the DHCP server.

• Add file - This is a file that lists MAC addresses that are allowed to access their reservation from this server and will be initialized via PCMGR (complete install including prompting for room number). This file corresponds to hosts added via the PCMGR SCHEDADD function described above. Entries in this file are removed as they are initialized.

• Address bracketing - When MAC or IP addresses are logged, they are bracketed with ">x.x.x.x<" symbols for easier pattern matching in external log related functions. Preferably, when determining if a specific MAC address will be given an IP address, the deny file is checked first and then the allow file. Rembo A module that provides low-level PXE boot capabilities and disk image functions should be included in PCMGR. PXE stands for Pre-boot Execution Environment which is a component of Intel's Wired for Management specification. The PXE model provides computers the ability to load and execute a network bootstrap program (NBP) from a server on the network prior to booting the OS on the local hard drive. This is done remotely which eliminates the need to visit machines and boot them with floppy disks. When a PXE enabled device boots, it obtains an IP address from the PCM-DHCP server, it then discovers the Proxy DHCP server that provides the remote device with a list of Boot Servers. The remote device obtains the name of the network bootstrap program (NBP) from the appropriate Boot Server. Finally, the remote uses TFTP to download the NBP from the Boot Server and then executes it.

The PXE module should create image files and that then can be installed on remote systems via encrypted unicast or multicast transfer. The module should also provide extensive scripting capabilities that allow operations such as disk partitioning, formatting, and image extraction to be performed under programmatic control. A commercial product, such as Rembo by Rembo Technology Sari, 48 rte des Acacias,

CH-1227 Carouge, Switzerland may be used as the PXE module. The Rembo software runs on the central server. Portions of the Rembo software may be securely downloaded to the PC system. Rembo's actions are directed via PCMGR and the programs described in the RBCSRC section below. The Rembo server preferably uses its own filesystem overlaying the Linux filesystem. The reason this is done is because Rembo supports multiple server platforms and using a common filesystem insulates Rembo clients from the underlying server filesystem implementation. RBCSRC

The Rembo-C compiler (RBC) Source files (SRC) may be provided to direct the activities of the Rembo server with a specific PC while performing imaging operations. The source files should be written in "Rembo-C" which is very similar to the "C" programming language. The following source files may be provided:

• redir - The redir file is the "home page" that all PC systems load as they boot into Rembo. The file contains both HTML and Rembo-C directives. The redir file first defines the location of a background file and defines the global error handler. Then the global multicast speed is set, and checks are made to see if multicast should be used for the current operation. Then redir checks to see if the host has an "re" file in its Rembo "home directory". If it does, it means the PC is already in the system and executes the re file. If not, redir assumes the box is a new system and begins the initialization process on it (loadinit). If a device's "re" file is deleted, it should begin the init process at next boot, including prompting for a room number. This file should not be deleted or modified manually.

• loadinit.rbc - This file is responsible for the initial preparation of a PC that is to be added to the system. It first creates a variable defining the system's state (i.e., "init"). It then partitions the hard drive. The "util.img" image file is restored to the second partition - a custom config.sys, autoexec.bat, CMOS settings file, etc., and the current "pcmake.exe", described below is copied to the partition. DMI information is gathered by the Rembo executable "dmi.rbx" from the new system and written to the file "dmi.txt" on the second partition. The Rembo executable "initchain" is then copied to the current system's run file in the Rembo filesystem (this will be run at next reboot). At this point all buffers are flushed to disk, and the system is booted (not rebooted) from the second partition, executing the custom autoexec.bat and ultimately pcmake.exe. Pcmake.exe displays the system information found and prompts for a room number. The information is gathered and written to file ("C:\pcid") for future processing by "initchain" and ultimately

PCMGR. Pcmake.exe then creates a batch file containing the commands necessary to flash the BIOS, change CMOS settings, and then reboot the system. Pcmake.exe then exits, releasing its memory and transferring control (via AUTOEXEC.BAT) to the newly created batch file. The system BIOS is flashed, CMOS settings changed, and the system reboots.

• initchain. bc - This is essentially the second half of initialization and does most of the work not requiring user input. The system state variable is first changed to "initchain". The background screen is then displayed and the previously created "pcid" file is copied up to the server. Depending on which platform "pcmake.exe" detected, a platform id file is used to determine which images to load during this state. Using this information, initchain then gets BIOS version information, and begins image restoration. First the platform specific Windows 2000 image is downloaded to the cache partition and restored to the first partition. Then a generic "reboot" image is downloaded to the cache partition and restored to the second partition. Once this is done, the Windows 2000 hostname is modified to be the same as its MAC address. Then the current "version.txt" file from the restored Windows 2000 image is copied to the server. At this point, patch installation begins. First a platform specific "global" patch file is executed to load platform specific patches and games. This patch file then looks for and executes (if exists) a host specific patch file, allowing per PC system customization. Once these patch files exit, control is returned to initchain. The file "loadrun" is then copied to the current system's run file in the Rembo filesystem (this will be run at next reboot). The system then boots (not a reboot) Windows 2000 and does a "Device discovery boot". Ultimately PCMA will then reboot the system after device detection, causing "loadrun" to be executed at the next boot.

• loadbios.rbc - This file is used to control a BIOS flash/CMOS setting operation for a PC. First the system state variable is changed to "bios". The generic "util.img" is restored to the second partition (the first partition containing Windows 2000 is not modified). The "bios.ver" file for the proper platform is copied to the server and a platform specific autoexec.bat file is created containing the commands to flash the BIOS and set CMOS settings. The file "loadrun" is then copied to the current system's run file in the Rembo filesystem (this will be run at next reboot) and the system is booted to the second partition transferring control to the autoexec.bat. The BIOS is flashed and CMOS settings updated, and then the system reboots.

• loadcache.rbc - This file is used to control a CACHE refresh of a PC system. The system state variable is first changed to "cache". The background screen is displayed and then, depending on the platform, a specific Windows 2000 image is restored from the cache partition to the first partition, and then a generic "reboot" image is restored from the cache partition to the second partition. Once this is done, the Windows 2000 hostname is modified to be the same as its MAC address - also the current "version.txt" file from the restored Windows 2000 image is copied to the server. At this point, patch installation begins. First a platform specific "global" patch file is executed to load platform specific patches and games. This patch file then looks for and executes (if exists) a host specific patch file, allowing per PC system customization. Once these patch files exit, control is returned to loadcache. The file "loadrun" is then copied to the current system's run file in the Rembo filesystem (this will be run at next reboot). The system then boots (not a reboot) Windows 2000 and does a "Device discovery boot". Ultimately PCMA will then reboot the system after device detection, causing "loadrun" to be executed at the next boot.

• loadfull.rbc - This file is used to control a FULL reload of a PC system. This operation is similar to a CACHE function, however, the disk is completely repartitioned and any existing Rembo cache partition is destroyed. All images must be reloaded again from the server. First the system state variable is changed to "full". The background screen is displayed and then, depending on the platform, a specific Windows 2000 image is downloaded to the Rembo cache partition and restored to the first partition. A generic "reboot" image is copied to the Rembo cache partition and restored to the second partition. Once this is done, the Windows 2000 hostname is modified to be the same as its MAC address - also the current "version.txt" file from the restored Windows 2000 image is copied to the server. At this point, patch installation begins. First a platform specific "global" patch file is executed to load platform specific patches and games. This patch file then looks for and executes (if exists) a host specific patch file, allowing per PC system customization. Once these patch files exit, control is returned to loadfull. The file "loadrun" is then copied to the current system's run file in the

Rembo filesystem (this will be run at next reboot). The system then boots (not a reboot) Windows 2000 and does a "Device discovery boot". Ultimately PCMA will then reboot the system after device detection, causing "loadrun" to be executed at the next boot. • loadmaint.rbc - This file is used to place a system into Rembo maintenance mode. This mode is useful to create or modify Rembo images from a system. All I/O devices are activated (keyboard, mouse, screen) and the system state variable is changed to "maint". The background screen is displayed and then the Rembo console and an "Interactive Evaluator" are activated allowing the user to type Rembo commands. Once in this mode, the PC will return to maintenance mode even after subsequent reboots to allow real-time modifications to be made to a disk image for later Rembo imaging. • loadrun. rbc - This file is the "normal" startup script for a PC that is being turned on or rebooting. It simply makes some system checks and then boots the system from the local hard disk. First the system state variable is changed to "run". It then looks for either a monid file (monitor serial number) or prtid file (print queue mapping) created by the PCMA process and moves them to the server. The generic "reboot.img" file is restored to the second partition and the second partition is marked as active in the partition table. The reason the second partition is marked as active at this point is twofold - first if someone manages to bypass a network boot on the system, it will boot the active partition and simply reboot. Second, if the system BIOS falls through to a hard disk boot after a failed network boot (SOP on some platforms), the system will simply reboot and repeat the network boot process. A check is then made to see if the system is in a "checked out" status. If it is, loadrun writes a command file to the PCMA process to issue an alert trap (after Windows 2000 boots up) and simply power the system back off. All buffers are then flushed to disk and partition 1 is booted - loading Windows 2000. PCMA PCM Agent (PCMA) is a program that provides several functions, and can act as a remote extension of PCMGR on the client PC. PCMA preferably runs under control of the SVC service, described below, on the remote workstation. Some of the features that PCMA may provide include:

• Settings via configuration file - Since PCMA should support multiple platforms, with differing requirements, items such as allowed USB devices, processes to monitor, etc. can by modified via configuration file. • Scheduling priority adjustments - PCMA may adjust the priority of relevant processes.

• Local/Remote Command Execution - Rembo scripts, EPWRAP, and PCMGR send commands to PCMA by writing commands to a file whose contents contain commands to be executed. This can provide a single interface, and allow PCMA to execute scripted commands even when direct contact with a PCMGR process is not available. The scripted commands that may be executed include device detection reboot (during initialization, FULL, or CACHE operations), normal reboot, external program running, external program reboot, checkout power-off, and PCMGR power-off, among others. • SNMP trap generation - PCMA may send traps to the Trap Handler daemon running on the server for various situations including, for example: startup, user power-off, PCMGR power-off, system reboot, keep-alives, Screensaver starting, screensaver exiting, external program running, USB device detection and removal, normal and device detection reboot. • USB Device Monitoring - PCMA may monitor USB devices on the system and can detect the insertion of unwanted USB devices, remove relevant registry keys, and prevent device driver installation. PCMA can also monitor the status of USB based keyboard and mouse devices and send an alert when these devices are removed. In these situations a trap can be sent to the server, an alarm should sound on the PC, and then the PC should be shut down.

• Print queue re-mapping - PCMA may support remote printer queue re-mapping via PCMGR control. PCMA may handle changing the requisite registry entries and restarting the spooler service. This can allow printer assignments to be changed "on the fly" without interruption of service on the PC system. • Monitor Serial Number Detection - On devices equipped with VESA compliant monitors, PCMA should be able to extract "EDID" information gathered from the monitor through the video card connection. This "EDID" information may include the model and serial number of the monitor. This information should be ultimately stored within a database. This greatly improves asset tracking.

PCMA.EXE should be installed on the client PC and, from a security perspective, PCMA.EXE should run as a "SYSTEM" level process under Windows 2000, so even a local Administrator cannot directly terminate it. PCMA preferably has no RPC or Sockets based interface, and is not directly exploitable via network attack. Remote commands are received via SCP file copy, which is encrypted. In addition, PC SSH configuration is such that only the server IP address is allowed to communicate with the PC via SSH/SCP, described below. SVC A central control point for both the PCMA and SSH processes running on the client PC should be provided. In an exemplary embodiment, Service (SVC) provides this function. This process communicates with a Service Control Manager (SCM) on the PC to allow these processes to be started, stopped, and monitored. Due to the potential havoc it could cause, SVC should not shutdown the SSH service during a service stop operation. Doing this could leave the system in a state in which communications could not be re-established with the PC. Other processes could be easily added to SVC as needed for central control of processes on the PC. SSH/SCP

Secure Shell Protocol and Secure Copy Protocol are open source programs and may be used to provide remote command shells, remote program execution, and file transfer capabilities between the central server and client PCs. All authentication and data transfers are protected from traffic sniffing and "replay attacks" by strong encryption. Additionally, the configuration of SSH on the PC systems only allow connections from the central site server. Blowfϊsh is preferably used as the block cipher of choice due to its good balance of security and speed.

The SSH software should be installed as binaries on the PC platform and is considered part of the OS base image. The sshd.cfg file is preferably installed during the patch phase of the system, since it has been modified to only allow connections from the current IP address of the site server. PCMAKE

A module to determine PC Make, Model, Serial number, and other information should be contained within the system's DMI MIF and run during installation of devices. This information should be packaged for delivery to the central server. According to one embodiment, information gathered by the Rembo program is analyzed and the make, model, and serial number of the host PC is determined. PC information is displayed to the installer who is prompted for room number. The installer is also asked for confirmation of make, model, and room number. A batch file is created for the specific platform to flash the BIOS, configure CMOS settings, and then the device is rebooted. The gathered configuration information is written to "pcid" file. Control may then be transferred to the newly created batch file.

From this point, the batch file should flash the BIOS and configure CMOS settings and reboot the system. The "pcid" file that PCMAKE.EXE created will be transferred to the server via the "initchain" Rembo-C program, and ultimately to PCMGR for inclusion in configuration files and databases. Note: If something goes wrong during the PCMAKE process and a pcid file is not created, initchain will simply reboot into PCMAKE again. Refer to the description of "loadinit" and "initchain" in the RBCSRC section for more information on the operation of PCMAKE during the initialization process.

Additionally functionality may be provided to manage the remote devices. A number of commercially available software products provided additional functions. These products and any modifications that may be needed are described below. WinVNC

Administrators use WinVNC for remote screen monitoring and control of PCs. WinVNC can be installed as a service on remote PCs, however it is set to not start automatically. During a PCMGR operation in which the administrator desires the view the screen of a PC in the system, described above, PCMGR connects to the PC via SSH and turns on the WinVNC service. This is done not only for security reasons (other users on the network could attempt to authenticate and remote control the PC), but from a system resource standpoint as well - i.e., the PC runs slower while WinVNC is active. Browser only interface

A guest may desire to browse the Internet without needing full computer functionality. Therefore, a "locked-in" browser user interface that runs on the client PCs should be provided. Netshift Pro and Automated Kiosk Attendant (AKA) are commercial products available from Netshift Software Ltd., a privately owned company from England that may be used to provide a "browser only" interface to the PC system. These components run on the remote PC system and can provide additional security functionality such as keyboard blocking. NetShift and AKA are preferably installed as part of each platforms specific OS image. This includes the key-blocking components and the executable files. Ntldr.noF8 In a normal boot procedure for a computer using Windows 2000, for example, a user is given the opportunity to change the boot procedure. However, the remote devices system should not be brought up in safe mode in the field, other than a break-in attempt. Microsoft's Windows 2000 "ntldr" is therefore preferably customized to not display the "Press F8 for more boot options..." message. Furthermore, the Safeboot registry keys should be renamed during initial image creation. If a user presses F8 and attempts to bring up the system in any of the listed safe modes, the PC bugchecks screen is brought up. From this point, the only way to reboot the system is a hard power-off (hold power button for more than 4 seconds). Ultimately a version of ntldr with no F8 check at all is preferred.

Accordingly, a system and method for management of remote devices is provided. The method and system can provide a subscription PC system with remote management capability. Also, entertainment and personal productivity/generic computing functionality can be delivered through a single multi-service convergence device. The multi-convergence device may be provided with automated personalization and customization.

The embodiments illustrated and discussed in this specification are intended only to teach those skilled in the art the best way known to the inventors to make and use the invention. Nothing in this specification should be considered as limiting the scope of the present invention. The above-described embodiments of the invention may be modified or varied, and elements added or omitted, without departing from the invention, as appreciated by those skilled in the art in light of the above teachings. It is therefore to be understood that, within the scope of the claims and their equivalents, the invention may be practiced otherwise than as specifically described.

Claims

ClaimsWe claim:

1. In a network comprising a plurality of remote devices connected to a central server, a system for managing the remote devices comprising: means for adding remote devices to the network; means for deleting remote devices from the network; means for installing the remote devices to the network, including assign remotes devices IP addresses; means for remotely enabling specific functionality of the remote devices; means for remotely changing BIOS settings of remote devices individually; and means for remotely reformatting hard drives of the remote devices.

2. The system of claim 1 further comprising means for associating an IP address of a remote device with a room number.

3. A method for providing a services via a remote device, comprising:

connecting the remote device to a network; assigning the remote device an IP address; remotely enabling selected functionality of the remote device from a central server connected to the network via the Internet.

4. The method of claim 3 wherein the remote device is a convergent device.

5. The method of claim 4, wherein the convergent device provides concurrent video-on- demand and computing services.

6. The method of claim 4 wherein the remote device provides computing services.

7. The method of claim 6 further comprising remotely installing an operating system on the remote device upon receipt of authorization.

8. The method of claim 3 further comprising remotely controlling states of the remote device via the Internet with the central server.

9. The method of claim 3 further comprising storing a list of MAC address and only assigning IP address to those remote devices whose MAC addresses are in the list.

10. The method of claim 3 further comprising storing a list of MAC address that are not entitled to an IP address and not assigning IP address to those remote devices whose MAC addresses are in the list.

11. A computer useable information storage medium storing computer readable program code means for causing a computer to perform the steps of:

connecting remote devices to a network; assigning the remote devices IP addresses; and remotely enabling selected functionality of the remote devices from a central server connected to the network via the Internet.