Internet online backup system provides remote storage for customers using IDs and passwords which were interactively established when signing up for backup services6411943Abstract A user can use his personal computer to call up an on-line service system over a telecommunications link such as a telephone line. The On-line system provides all sorts of useful services to the personal computer such as antiviral protection, auxiliary processing capabilities, and other features that are impractical or inconvenient to provide locally. Claims What is claimed is: Description FIELD OF THE INVENTION
4,649,479 03/87 Advani et al.
4,982,324 01/91 McConaughy et al.
5,023,774 06/91 Sakai et al.
5,107,456 04/92 Schuur
5,109,515 04/92 Laggis et al.
S. Armbrust et al., PC Tech Journal, Vol. 3, No. 9, "Forward Looking VDI," September 1985, pp. 42-53 E. R. Carpenter, IBM Technical Disclosure Bulletin, Vol. 34, No. 10B, "Single System Image With Network File System," IBM Corp., March 1992, pp 408-409 M. Tabes, Datamation, "Managing Storage Across the Enterprise," May 1992, pp 36-40 P. Korzeniowski, Software Magazine, "Back to the Mainframe For Storage of LAN Data," July 1992, pp 73-77 Mark Ludwig, The Little Black Book of Computer Viruses, American Eagle publications, 1991, pp. 11-19, 23-29, 55-68, 69-76, 159-162 R. Waterman, Software Magazine, "Waiting for X500," July 1992, 2 pages R. Brown, Systems 3X/400, "Serving Many Masters," March 1992, pp 68-70 PC Computing, "Test and Evaluation Methods," June 1992, pp 238, 240, 247-248 and 262 Advertisement, "Data Rx," 1 page Price list, "Tape Backup," 1 page Advertisement, "Let's Talk.RTM., Tired of the Runaround?," 1 page Advertisement, "PC/TCP.RTM. Plus," 1 page Advertisement, News 3X/400, "Mimix Hi-Net, Lakeview Technology Inc., " September 1991, p 140 Advertisement, Network Innovation, "Server Based Backup," 1page Advertisement, News 3X/400, "PC File Mail," November 1991, p 74 Advertisement, "HandsOn Software, Monarch 36/400.TM. lets PC users get their hands on mid-range data," 1 page Advertisement, Andrew, "NetLynx.TM.: LAN Connectivity by the Numbers," 1 page Advertisement, "Innovation.RTM. Data Processing, FDR. Your DASD Management System," 1 page Advertisement, "Maynard.RTM., Maynard Delivers a Super Bundle," 1 page Advertisement, "Central Point Software Inc..RTM., Never Underestimate the Importance of Complete Protection," 1 page Advertisement, Business Communications, Gazelle, "Backup While You Work," June 1992, p. 436 Advertisement, "Works," 1 page Advertisement, "Intel.RTM., Introducing fax software that can send, receive and run with your faxes, 1 page Advertisement, "LapLink, With LapLink you're only a phone call away," 1 page M. Tischer, PC Systems Programming, Abacus, April 1993, pp. 157-171, 208-12, Appendix B and C Robert Jourdan, Programers Problem Solver, Prentice Hall, 1986, pp. 369-394, 395-406 The Waite Group, MS-DOS Developers Guide, Howard Sams & Co., 1989, pp. 281-354, 583, 739-748 Advertisement, PC/Computing, "Control up to 96 PC file servers with 1 keyboard and monitor using . . . Commander by cybex, p 433 Advertisement, PC/Computing, "SequeLink.TM., MiddleWare.TM.: Open Windows for Client/Server Computing," p 427 Advertisement, "System Software Associates, Inc., BPCS Client/Server Application Software, 1 page Advertisement, "Rochester Software Connection, Inc., What's fast, fun and does the AS/400?" 2 page One of the greatest limitations to existing on-line services is that no provisions are available to execute host based software on the remote user's system directly or for a user's locally executing application to directly access storage on the host system. The present invention provides an on-line service and associated equipment which solves these and other problems. A presently preferred exemplary embodiment of this invention provides the following advantageous features: A multi-user host provides a wide variety of on-line services to a plurality of remote computers via virtual device attachment. Virtual peripheral devices are attached to the remote customer computer via an on-line, temporary telecommunications link (e.g., a dial up telephone line) in the context of an on-line service. Customers can load executable code stored on host virtual devices directly into customer or "replica" server memory for execution without file transfer. Device drivers executed by the customer computer automatically manage I/O requests to replica server and host virtual devices as through they were locally attached devices. An automated recovery feature periodically (e.g., incrementally) archives the customer computer mass storage data onto a host "virtual disk drive." When recovery is necessary (e.g., due to failure of the local mass storage device), the customer computer may be initiated using a special boot diskette to boot the computer and automatically attach to the host virtual disk--thereby permitting the customer computer to operate essentially normally despite the failure of its local mass storage device. Software distribution can be provided on two levels. "Execute only" access to an executable program stored on host-provided virtual storage allows the user to run the program from time to time and/or permit the user to try the software out to determine whether a local copy is needed. Execute only access loads directly into the customer computer or replica server memory without creating an intermediate disk copy. Upon paying a fee, the user is granted copy access to permit downloading the file onto the customer computer local mass storage. Virtual storage device access includes automatic anti-virus detection in real time. The most recent anti-virus software releases are provided so that new virus strains will be detected while relieving the user from having to constantly update anti-virus software. Unattended access/attachment to the host (e.g., at a scheduled time during off peak hours) performs routine tasks such as incremental backup/archiving. Automatic diagnostic capabilities inform the customer about hardware and/or software problems with their computer. The host may route information between users and/or physical or virtual devices (e.g., to permit multiple users to have shared access to a common database, or customers to move information from one computer to another). On-line virtual output facilities such as production printing, facsimile, and electronic mail can be economically provided on a "pay as you go" basis. The host provides automatic billing capabilities and security facilities. User authorization to access the host may be granted by a "sign-up" system. The "sign-up" system may create a configuration file including password and other access information, and download the file to the user's workstation. Initial charges may be collected via a user-supplied credit card number. Alternatively, access to the "sign-up" system may be via a "special pay" telephone number (900) such that compensation is received by the service provider from the user via the telephone company billing system. A sophisticated signal process. A dialing pattern sent to a customer computer (e.g., a certain number of calls, certain number of rings each call, a certain wait period between each call) triggers the customer computer modem to switch into answer mode. Upon answer, an access code is optionally sent to the customer's computer that identifies a reason for the host call (i.e., dial back verification, host task completed on behalf of customer, mail or data waiting for download to customer, etc.). The host computer flags a customer record indicating the customer computer answered at the appropriate time (dialing pattern match), thereby allowing the customer computer to access the host. A Customer Signal file is used to queue the dial-up requests. This allows the host to trigger the customer to call the host when needed, and also allows the customer to be certain that only his computer can access the service. When the customer calls the service first, the service hangs up and queues a dialing pattern to be sent to the customer. Only when the customer computer answers after a certain dialing pattern will the host computer allow the customer entry. The customer accesses the service, but only after the host flags a dialing pattern match. If the host dials the customer first and gets a pattern match, then the customer can access the system immediately without this dialback sequence. A computer of similar type to the customer (Off-line "Replica" Computer) performs task that require an identical processor type to the customer, thus freeing the customer computer to perform other activities. Request data is written by the customer and read by the Replica computer to perform these tasks. The Replica computer task has access to data secured by the user but available only to the customer and the replica task (i.e., routing disks, etc.). Prompts and information are supplied before the request is queued, and the replica computer automatically enters the necessary keystrokes to achieve the task using the prompted information stored with the request data. A Replica Request file is used for the data. A 900 area code phone number is used for pay access to services. A customer processor executes commands from the host. All requests for services are initiated by a host command that in turn may execute a customer computer processor command. Host based anti-viral programs are loaded and executed in the customer processor to protect access to programs and data. Virtual devices to allow the execution of host based software within the customer processor. Host Request information maintained in a Host Request File causes commands to execute on the host which may in turn cause commands to execute within the customer processor. A host based controlling command for each service option and a router security intercept program which track the start and end time for billing purposes whenever a command executes within the customer processor. Media, documents and the like can be converted by using a replica of the customer's computer running translation or conversion software against data stored in virtual devices by the customer. The service allows customer access to on-line service data by the customer computer processor by attaching to the data as a virtual drive. Data and programs can be rented by using a host control program to restrict attachment to virtual disks holding the data and programs. A host command is used to direct the router to initiate execution of a specified program in the customer's processor. Data and programs can be purchased/licensed by moving them from a restricted virtual disk to a virtual disk created for and owned by the customer using a host control program. Automated release update services maintain a table of software owned by the customer that is allowed to be updated. Release update data and programs can be transferred from a restricted virtual disk to the customer computer disks or virtual disks using a host control program. A security program verifies types of access to restricted virtual devices attached by a control program but currently accessed by a program executing within the customer's processor. Control information is transferred between the host computer and the customer computer to manage on-line service requests. A host controlling program executes programs in both the host processor and customer processor separately or at the same time within a given process to achieve desired results. Programs residing on the host system but executed within the customer processor are executed as though they are directly available to the customer computer operating system using a host control program. In the case of on-line service access via special charge telephone numbers, Telco's use On-line Service billing time and access charges to assess fees which appear on the customer's Telco statement. Request completion information is maintained on the host. This information is displayed to the customer on subsequent accesses, or the customer is alerted of a completion by sending a dialing pattern and access code to identify the type of message or trigger the customer computer to call the on-line service. The customer computer automated access program can identify a lockup condition and break out of the task to continue with additional requests. The host computer identifies a lockup condition and cancels the program or session to allow the customer computer to continue with additional requests. BRIEF DESCRIPTION OF THE DRAWINGS These and other features and advantages provided by the present invention can be more completely and better understood by referring to the following written description of a presently preferred exemplary embodiment in connection with the drawings, of which: FIG. 1 schematically shows an on-line service system connected to a user's personal computer in accordance with the preferred embodiment of the present invention; FIG. 2 illustrates various examples of services provided by the preferred on-line service system of FIG. 1; FIG. 3 schematically illustrates the components within the preferred on-line service system and the customer computer; FIG. 4 is a detailed schematic diagram showing various different arrangements for connecting the on-line service system to customer computers; FIG. 5 is a schematic diagram showing one example of remote disk drive sharing in the preferred embodiment; FIG. 6A schematically illustrates overall functional connections provided by the preferred embodiment on-line computer system to make virtual devices available to the customer computer and other system components; FIG. 6B schematically illustrates overall functional connections provided by the preferred embodiment on-line computer system to process customer computer signalling; FIG. 6C schematically illustrates, on a high level, the basic way in which the preferred on-line computer system handles on-line service requests; FIG. 6D schematically illustrates, on a high level, the basic way in which the preferred on-line computer system handles off-line service requests; FIG. 6E schematically illustrates different processing functions performed by the host computer, replica computer and customer computer in the preferred embodiment; FIG. 7 schematically illustrates, on a more detailed level, some of the major tasks performed by the customer computer in the presently preferred embodiment; FIGS. 8A and 8B schematically illustrate, on a more detailed level, some of the major tasks performed by the host computer system in a preferred embodiment; FIG. 9 schematically illustrates, on a more detailed level, some of the major tasks performed by the replica computer in the preferred embodiment; FIG. 10 is a high level flow chart of exemplary tasks performed by the customer computer in the preferred embodiment during startup; FIG. 11 is a schematic flowchart of the "re-direct interrupt" block of FIG. 10; FIG. 12A is a schematic flowchart of exemplary keyboard interrupt handler tasks in the preferred embodiment; FIG. 12B is a schematic flowchart of exemplary timer interrupt handler tasks in the preferred embodiment; FIG. 12C is a schematic flowchart of exemplary communications interrupt handler tasks in the preferred embodiment; FIG. 13 is a schematic flowchart of exemplary tasks performed by the customer computer during an on-line session with the on-line service system in the preferred embodiment; FIGS. 14A-14H are more detailed schematic flowcharts of the "begin customer server router" block of FIG. 13; FIG. 15 is a flowchart of exemplary program control steps of the "security check" block of FIGS. 14A-14H; FIGS. 16A-16C are schematic illustrations of exemplary data structures maintained by the customer computer in the preferred embodiment; FIG. 17 is a schematic flowchart of exemplary program control steps performed by the host computer in the preferred embodiment; FIG. 18 is a flowchart of exemplary program control steps performed by the "begin host security program" block shown in FIG. 17; FIGS. 19A and 19B together are a flowchart of exemplary program control steps performed by the host computer system as part of the "begin signal customer task" block shown in FIG. 17; FIGS. 20A-20B together are a flowchart of exemplary program control steps performed by the host computer system of the preferred embodiment to effect the "begin host request task" block shown in FIG. 17; FIGS. 21A-21E together are a flowchart of exemplary program control steps performed by the host computer system in the preferred embodiment to effect the "begin customer session" block shown in FIG. 17; FIG. 21F is a flowchart of exemplary program control steps performed by the host computer system in the preferred embodiment to effect the "begin off-line replica session" block shown in FIG. 17 to manage the operations of an off-line replica computer; FIGS. 22A-22G schematically show exemplary data structures maintained by the host computer system in the preferred embodiment; FIG. 22H schematically shows some of the request options available to on-line service customers in the preferred embodiment; FIG. 23 is a flowchart of exemplary program control steps performed by the on-line replica computer in the preferred embodiment; FIGS. 24A-24J together are a flowchart of exemplary program control steps performed by the replica computer of the preferred embodiment to effect the "begin replica server router" block of FIG. 23; FIG. 24K is a flowchart of exemplary program control steps performed by the preferred embodiment replica computer to effect the "security check" block in FIGS. 24A-24J; FIG. 25A schematically illustrates exemplary data structures stored by the replica computer in the preferred embodiment; FIG. 25B schematically illustrates some of the requests managed by the customer and replica server router programs in the preferred embodiment; FIG. 26 is a flowchart of exemplary program control steps performed to boot up and operate the off-line replica computer in the preferred embodiment; and FIG. 27 is a flowchart of exemplary program control steps performed by a preferred embodiment on-line service sign-up computer in order to issue new account numbers for the on-line service. DETAILED DESCRIPTION OF A PRESENTLY PREFERRED EXEMPLARY EMBODIMENT I. CUSTOMER COMPUTER ON-LINE SERVICE NEEDS FIG. 1 shows a preferred example of a customer computer 50 accessing an on-line service system 100 in accordance with a presently preferred exemplary embodiment of this invention. Customer computer 50 may for example be a standard personal computer including a main processor unit 52, a display 54, a keyboard 56, and a mouse 58. Main processing unit 52 typically includes a floppy disk slot (drive) 60 that reads floppy diskettes 62. Customer computer 50 performs tasks for a user under software control, and displays the results of the tasks on display 54 (an optional printer can be connected to main processing unit 52 in order to print out the results). New software can be loaded onto customer computer 50 by storing the software on floppy diskette 62 and inserting the floppy diskette into disk slot 60 so that it can be read by the main processor unit 52. The user operates keyboard 56 and mouse 58 to interact with the software tasks performed by computer 50. Customer computer 50 as described above is a self-contained, stand-alone unit that is capable of performing a wide variety of processing tasks without having to be connected to any other computer equipment. For example, the user can run a word processing program to key in new documents for storage within the main processor unit 52. The user can also perform financial calculations using a spreadsheet program, and store the results of the calculations again within main processor unit 52. Depending upon the software loaded into main processor unit 52, the user may be able to perform a wide variety of additional software tasks such as, for example, video games, check book management, graphics generation program, etc. The variety of different tasks customer computer 50 is capable of performing is determined by the availability of software needed to perform the tasks. Although customer computer 50 is capable of doing many different tasks all by itself, it has certain limitations. For example, there may be no printer attached to customer computer 50 such that it is not possible to print out hard copy of the results of the processings performed by the customer computer. Even with a printer, it may take a very long time to print out certain results and the user may not want to tie up his printer for such a long time. Similarly, the user may not wish to spend the money to buy various expensive peripheral equipment that could be connected to customer computer 50 (e.g., Fax boards, CD ROM drives, voice boards, multi-media equipment, etc.) but would nevertheless like on occasion to have some of the capabilities associated with this added equipment. Another serious limitation of customer computer 50 relates to the amount of storage it has. Typically, a so-called "hard disk" within main processor unit 52 is used to store all of the data generated by the customer computer 50 as well as all of the software to be executed by a customer computer. Auxiliary storage capabilities are provided by floppy disk slot 60 and floppy diskettes 62. Unfortunately, the hard disk internal to main processor unit 52 may run out of space to store additional data or programs, or it may fail and lose all of the data it previously stored. The user can "back up" the data stored on the internal hard drive using floppy diskettes 62, but this can be a long and tedious process and the user may sometimes forget to do it. The user could, of course, upgrade his customer computer 50 by adding additional internal or external storage devices, but this would be expensive and might not be cost effective. Nevertheless, the limitations on the storage capabilities of customer computer 50 may be troublesome to the user at times (e.g., if a hard disk failure does occur, of if the user wants to try out a new program but does not have the space on his hard drive to load the new program onto it). Another limitation of customer computer 50 relates to the variety of different software it can run. Customer computer 50 can only run software that has been loaded onto it. In order to perform a new function or task, the user must obtain floppy diskettes 62 containing a new program from a software store, and then use floppy disk slot 60 to input the new software to main processor unit 52 (e.g., to load the new software onto the internal hard drive within the main processor unit 52). If the new software is a big program, this loading process can take a lot of time. In addition, the loading process may be confusing to the user. Moreover, there is no convenient way to "try out" or temporarily rent or use software with customer computer 50. For this reason, the user of customer computer 50 may only be able to run a relatively small number of programs, and it is difficult to add new programs to that limited repertoire. Another problem that the user of customer computer 50 commonly confronts is outdated software. Most software companies are constantly improving their offerings. Each time a new version of software becomes available, the user must obtain the software on floppy diskettes and go through the time-consuming and sometimes confusing process of loading the software onto main processor unit 52 via diskettes 62 and floppy disk slot 60. This is especially a problem with certain software that must be updated constantly in order to remain effective. For example, it is a good idea for the user to run virus detection software on customer computer 50 in order to prevent the computer from catching viruses introduced when new software is loaded onto the computer. Because new "strains" of viruses are always being developed, and because virus protection software is typically effective only against those particular strains it has been programmed to recognize, it is essential for the virus protection software to be updated as often as possible so as to be able to detect even the newest strains. This is very inconvenient for the user, since it requires the user to constantly procure updated versions of the virus protection software and load them onto customer computer 50. II. ON-LINE SERVICES GIVE CUSTOMER COMPUTER WHAT IT NEEDS These and other problems and difficulties are eliminated when customer computer 50 connects to an on-line service system 100 provided by the preferred embodiment of the present invention via a data link 150 as shown in FIG. 1. Data link 150 may comprise a dial up telephone line or other similarly convenient telecommunications link that allows customer computer 50 to be located remotely to the on-line service system 100. The on-line service system 100 provides various capabilities (e.g., data storage, program storage, processing, and input/output devices) that enhance the operations of customer computer 50 in order to solve the drawbacks and problems mentioned above. On-line service system 100 provides software and computing services to customer computer 50 in return for fees. Such software and services can be extremely valuable to the user of customer computer 50 in that they provide enhancements to the operation of the customer computer that were available either not at all or only through great expense and/or inconvenience. FIG. 2 is a schematic illustration of some of the various capability enhancements that on-line service system 100 can provide to customer computer 50, including the following: Anti-Viral Services (block 200) are provided by accessing anti-viral software stored on virtual disk. Anti-viral programs can be copied or executed directly. Anti-viral updates offer customers the latest anti-viral technologies. Offsite Archival Services (block 202) are performed by accessing virtual disk drives. Customer files inactive for a specified period are automatically copied to on-line service virtual disks for offsite archiving. Many disks of varying size can exist for each customer. Virtual disks are mounted and customer files are copied to their original customer disk for restoration. Virtual disks inactive for a specified period can be copied to on-line service tape for long term offsite archival. A virtual disk can be considered an offsite archival storage area. Every customer file could be stored on virtual disk with directory structures maintained. A diskette 62 can be provided to boot a customer computer and connect to the on-line service and boot a virtual disk copy of the customer computer system disk. An advantage virtual disks provide for offsite archival is that remote storage is accessible as if locally attached. Diagnostics and Maintenance Services (block 204) include various programs stored on virtual disks to checkout, troubleshoot, and enhance the customer computer 50. Diagnostic programs can detect problems with memory or system board components. Peripheral management programs can be used for testing, alignment, storage maintenance, etc., to improve device throughput. Hardware errors detected by diagnostic programs during a customer automated session can trigger repair service based on a maintenance agreement. Electronic Media Services (block 206) are designed to facilitate media transport by using an on-line service with virtual disks. Files stored in originating media format (WP, Fax, Image, etc.) can be copied to a customer "routing" virtual disk. A customer computer 50 accessing a virtual disk can convert a file from one media format to another (i.e., Fax to WP, WP to voice, etc.). On-line service peripherals provide further services such as transmitting to a fax unit or distributing a printed report. Customer Drive Services (block 208) allow customer access to virtual disks under on-line service session control. A customer can have multiple virtual disks mounted at the same time. During the course of an on-line session, a customer can mount and dismount many different virtual disks. Virtual disks can be shared by multiple users or by groups of users. Virtual disks can be made public to all, or secured for single user access. Program & Information Rental Services (block 210) are provided by offering secured access to host virtual disks with rental programs and data. Access security software protects against unauthorized copying. One time, per use, and/or time charges are assessed for information and program access. Program & Information Sales Services (block 212) are provided by copying software from a protected virtual disk to a customer's local or virtual disk upon receipt of payment. Demos can be offered by copying software to a temporary customer virtual disk. The temporary disk is deleted if payment is not received within a specified period. Demos common to all customers can be provided by accessing a shared, execute only virtual disk. Software Update Services (block 214) are provided by attaching to virtual disks and copying files to customer disks. A control program automatically determines the software or data to update. Batch files are typically used to automate the release update process, particularly when changes in configuration definition are required. "One Time" Services (block 216) describes services for providing undefined users access on-line services. Charges for a one time customer on-line service access appear on the customer telephone bill. Customer access for one time services is also provided by generic user ID. These generic user ID's are only allowed when the controller's modem is attached to a Telco pay exchange phone number in the preferred embodiment. The one time customer can access most on-line services except offsite archival. III. PREFERRED SYSTEM ARCHITECTURE FIG. 3 is a schematic illustration showing internal components within customer computer 50 and on-line service system 100. As described above, customer computer main processor unit 52 includes a floppy diskette drive 60a having the slot 60 shown in FIG. 1. In addition, the main processor unit 52 includes an internal hard disk 64, internal random access memory 66, a processor 68 and input/output ("I/O") controllers 70. I/O controllers 70 allow communication between the main processor unit 52 and external peripherals such as keyboard 56, mouse 58, and additional optional external peripheral equipment (e.g., a tape drive 72, a Fax unit 74, a printer 76, and/or a CD ROM drive 78) Main processor unit 52 also includes a modem 80. A modem is a conventional device which allows customer computer 50 to communicate over data link 150 with another computer having a similar modem. In the preferred embodiment, on-line service system 100 includes a modem 102 that is connected between data link 150 and a host computer 104. Host computer 104, which comprises an IBM AS/400 in the preferred embodiment, includes one or more main processors 106, internal random access memory 108, peripheral controllers 110, and communication controllers 112. Peripheral controllers 110 allow main processor 106 to communicate with various peripheral devices such as, for example, one or more high-speed printers 114, one or more mass storage disks 116, and other mass storage devices such as a tape storage device 118. Additional peripheral devices such as CD ROM drives, Fax machines and the like (block 120) may be also be provided and coupled to main processor 106 via the peripheral controller 110. In addition, one or more local display devices 122 may be connected to host computer 104 to allow local control over the host computer. The AS/400 is preferred as host computer 104 in the preferred embodiment due to its flexibility in terms of providing a multiprocessor system with object based security, workstation emulation, and virtual device access. However, other types of computers providing the required functionality could be used instead. FIG. 4 represents some common communication links 150 available to on-line service customers. A host computer 104 is shown with various attached peripherals including disk 116, tape 118, and printers 114. Communications Controllers 112 attached to the host computer 104 include digital (ISDN), Public Data Network (X.25), LAN Attachment Card, ASCII controller, and customer replica computer 160 running host workstation emulation software. Each controller 112 is connected (with or without modem 102) to a telecommunication relay station 124a. Data may be transmitted between two switching stations 124a, 124b by several means including satellite 126, fiber optic link 128, microwave link 130, Public Data Network 132, or cable TV link 134. For example, Customer computer 50(W) accesses system 100 via LAN attachment card 82 connect or remote session gateway connect (not shown). Customer computer 50(X) connects to the host with an ISDN digital link 84. Customer computer 50(Y) uses a modem 80b to connect to the host computer ASCII workstation controller 112a or the replica server computer 160. Customer computer 50(Z) connects to the on-line service using a coax cable connection 86. FIG. 4 shows that data link 150 may comprise up to three different "layers" of connection: the first layer or sub-link connects host computer 104 to switching station 124a; the second "layer" connects switching station 124a to switching station 124b; and the third "layer" connects switching station 124b to a customer computer 50. A customer may connect the on-line service system 100 by many different methods. These methods may evolve as advances in telecommunications become available. For example, each of the various layers may comprise any of ISDN link, LAN/WAN connect, a "front end controller," another computer, a telephone company connection, a direct connection, a fiber optic link, a cable television link, cellular link, a satellite link, a radio frequency link and/or a PDN connection. The three layers can also comprise varying cable mediums and software bridges, gateways, routers and/or emulations. On-line service system 100 also includes at least one (and typically many) "replica computer" 160. Replica computer 160 is connected to host computer 104 via communication controllers 112, and is also capable of connecting directly to customer computer 50 via a modem 162. Replica computer 160 is the same type of computer as is customer computer 50 and thus may be used to perform the same types of processing that customer computer 50 is capable of performing. This replica computer 160 adds processing capabilities to host computer 104 (which may be a different type of computer not capable of executing the same software that customer computer 50 is capable of executing). In the preferred embodiment, replica computer 160 is capable of operating in an on-line mode or in an off-line mode. In the on-line mode, the replica computer 160 communicates interactively with customer computer 50 to perform processing tasks. In this on-line mode in the preferred embodiment, the customer computer 50 and the on-line replica computer 160 cooperate to support processing in either and/or both processors (shared access to data buffers and a record locking scheme is used to ensure safe access). In the off-line mode, replica computer 160 performs personal computer tasks in response to direction from host computer 104 without having an on-line, interactive link with customer computer 50. In the preferred embodiment, the replica computer(s) 160 is locally attached to host computer 104 using workstation emulation hardware/software (e.g., a 5250 emulation card for connection to an AS/400 host computer). The replica computer 160 connects to the customer computer 50 with personal computer communications software using modems connected to communications ports COM1 on each of the computers. The on-line replica computer 160 is used to facilitate customer access to host computer virtual disks by seamlessly integrating a replica of the customer computer into the communications link 150. The replica computer 160 loads device drivers and runs communications software to establish a host session and access host virtual disks. "Dual redirection" of drives provides the replica computer 160 with access to drives of customer computer 50, and also provides customer access to replica drives (including, for example, host virtual disks). The presently preferred exemplary embodiment of this invention provides a disk sharing utility between replica computer 160 and customer computer 50. In this unique arrangement, the local hard drive 164 of the replica computer 160 can be "attached" to customer computer 50, and the customer computer local hard drive 64 can be "attached" to the replica computer 160. This allows the replica computer 160 to write to and read from the customer computer local hard drive 64 and also allows the customer computer 50 to write to and read from the replica computer local hard drive 164. Combined with controlled redirection of keyboard, mouse, video and printing, execution during a replica computer 160 on-line session can occur in the customer computer 50 or replica computer with user transparency. The off-line replica computer 160 performs tasks on behalf of the customer without a customer connection. Batch requests including parameters and script file data are stored in a Replica Request file (maintained by host computer 104 in the preferred embodiment) with a date/time to execute. The Off-line Replica computer 160 accesses the host computer with special authorities to certain customer virtual disks. The Off-line Replica computer 160 reads Replica Request data and when the time condition is met, the request is processed as if it were performed by the customer. IV. "VIRTUAL" DISKS In the preferred embodiment, host computer 104 may provide one or more "virtual" disk drives to customer computer 50. In addition, in the preferred embodiment on-line replica computer 160 may provide one or more "virtual" disk drives to customer computer 50, and the customer computer may provide one or more "virtual" disk drives to the on-line replica computer. In the context of this patent specification, a "virtual device" is an arrangement that "simulates" or "emulates" a locally-attached, physical device. For example, a "virtual disk drive" can be an arrangement (e.g., some combination of local and/or remote hardware and/or software) that "looks like" a physical drive. In the preferred embodiment, "virtual disk drives" allow the customer computer 50 to access resources as if those resources were actually a physical disk device locally attached to the customer computer. Since the customer computer 50 and its associated operating system and application software is already conditioned to efficiently access locally attached physical disk drives, the customer computer 50 can very easily access the "virtual disk drives" without any change in operating system or application software or additional overhead (other than software needed to support the virtual disk drive). Since the "resources" that emulate the locally attached physical drive to create the "virtual disk" can comprise, in part, a data link 150 and resources remotely located to the customer computer 50, virtual disks can provide great flexibility in allowing customer computer 50 to very efficiently access remotely located computer storage. Since in the preferred embodiment, the host computer 104 and/or replica computer 160 controls this remote storage, "virtual disks" provide an efficient means to allow the customer computer 50 to have access to particular data in a manner chosen by the operators of system 100. One example of a "virtual disk drive" provided by the preferred embodiment is a "virtual disk drive" that host computer 104 attaches to customer computer 50. Although host computer 104 may have several physical disk drives 116, those drives typically are not directly accessible by the operating system of customer computer 50, and in any event are remote to the customer computer and hence cannot be directly accessed by the customer computer as one of its local drives. Host-provided "virtual disks" are actually "objects" (e.g., files or some other data structure) stored by host computer 104. These objects may be physically stored on host disk 116 and/or host random access memory 108. Through software executed by host computer 104 and cooperating software executing on customer computer 50 and/or replica computer 160, these virtual disks can be "attached" to customer computer 50 and/or replica computer 160, and appear to those computers 50, 160 as additional, locally attached physical drives. In other words, the operating systems of computers 50, 160 can access these virtual disks in the same way they access a locally attached physical disk drive. Thus, customer computer 50 operating system can write to and read from a virtual disk in essentially the same manner that it can write to and read from its own local hard disk 64. In addition, the host computer 104 can supply commands and/or programs on the virtual disk for execution by the customer computer 50 in order to provide remote control features. For example, control programs stored on host computer 104 read-only virtual disks can be used to set "processor flags" on the customer computer 50 and the replica computer 160. Other control parameters on the customer or replica computers are similarly changed by control programs stored on host virtual disks. These programs are typically called by a command issued by host computer 104 used to execute personal computer commands in the attached personal computer (replica computer 160 or customer computer 50). Host computer 104 can create a "virtual disk" from memory resources, disk resources or typically, both memory and disk resources. Information written by customer computer 50 to a host computer "virtual disk" is typically temporarily stored within host computer memory 108, and is eventually more permanently stored on host physical disk ("DASD") 116 for later retrieval by the host, the customer computer that stored the information, or some other customer computer. The operator of system 100 can, of course, store information onto host virtual disks (e.g., by inputting the information via a replica computer 160) so that the information can be accessed by customer computer(s) 50. Communications software and device driver programs executing on customer computer 50 cooperating with communications and other software executing on host computer 104 make it possible for the customer computer to access these host computer memory and disk resources as if they were a physical, locally attached disk device. Although the host computer 104 can also manipulate and process data objects stored on such "virtual disks," it typically cannot execute an executable PC file stored on the virtual disk because in the preferred embodiment the host computer has a different operating system than does customer computer 50A. Host computer 104 provides "virtual disk drives" to customer computer 50 and replica computer(s) 160 in the preferred embodiment through use of conventional software available from IBM. In the preferred embodiment, host computer 104 comprises an IBM AS/400 mid-range computer providing "PC Support" virtual disk, print and other associated functions. As explained above, the IBM-provided PC Support Software makes it easy to attach a "virtual disk" or virtual printer to a remote or local personal computer such as customer computer 50. For DOS machines, "PC Support" requires that certain device drivers (EIMPCS.SYS and ECYDDX.SYS) are resident in the memory of the customer computer 50 or replica computer 160 to provide memory management and PC to AS/400 routing support (of course, this technique can be used with other operating systems such as OS/2, Unix, etc. using appropriate virtual device and workstation software). These device drivers are loaded from the PC CONFIG.SYS file during the PC IPL process. Other programs are loaded during host session initiation to provide workstation and virtual device access. Different "shared folder" types (0, 1 and 2) provide different performance based on different overhead requirements (e.g., personal computer memory usage). The AS/400 allows a personal computer to attach to a "shared folder" as a "Folder Drive" this allows the PC user to assign a drive letter to a specific folder, or as a "System Drive" (this allows the PC user to assign a drive letter to all the folders the user is authorized to access). Using this method, the DOS Change Director (CD) command can be used to change from one virtual disk drive to another, and normal operating system commands can be used to access and manipulate the virtual disks. The preferred embodiment of the present invention also makes "virtual disk drives" available to customer computer 50 in the context of an on-line session between a customer computer 50 and an on-line replica computer 160A. In the preferred embodiment, for example, a customer computer 50 can access a disk drive that is locally attached to on-line replica computer 160, and the on-line replica computer can access a disk drive that is locally attached to the customer computer. In the preferred embodiment, the resources that form the basis of the virtual disk may comprise a physical disk drive locally attached to one of the computers (e.g., the hard drive 64 of customer computer 50), or it may comprise a "virtual drive" (e.g., RAM disk, host-provided virtual disk, etc.). In the preferred embodiment, these drives are shared between two computers (e.g., customer computer 50 and replica computer 160) so as to allow each computer to seamlessly access the disk drive(s) of the other computer. For example, assume that customer computer 50 has designated its local floppy diskette drive 60 as its "A" drive, and has designated its local hard disk 64 as its "C" drive. The user of customer computer 50 has become accustomed to these designations, and it would be very confusing to change them for when the customer computer connects to on-line replica computer 160. Nevertheless, it would be useful to allow the customer computer 50 to access some or all of the disk drives (physical and/or virtual) of replica computer 160 during an on-line session as if those replica computer disk drives were local to the customer computer. In the preferred embodiment, the normal disk drive mapping of the customer computer 50 is not disturbed (i.e., "A" remains the local floppy diskette drive 60, and "C" remains the local hard disk 64). Instead, the disk drives of the replica computer 160 are "attached" to the customer computer 50 as "virtual disk drives," and are given designations by the customer computer that do not conflict with the designations reserved for customer computer local drives (e.g., the floppy diskette drive of the replica computer might be designated "D," and the replica computer hard drive might be designated "E"). Each of the customer computer 50 and the replica computer 160 is able to access execution resources (i.e., processor) and drive resources (i.e., shared virtual disk(s)) made available by the other computer. Where a particular command is executed depends on the state of a "processor flag" stored on the computer from which the command originated. Thus, commands inputted at the customer computer keyboard 56 will be executed by the customer computer processor 68 if the "processor flag" at (i.e., maintained by) the customer computer is set to "customer computer". On the other hand, commands inputted at the customer computer keyboard 56 will be executed by the replica computer 160 processor if the "processor flag" at the customer computer 50 is set to "replica computer". Similarly, commands inputted at the replica computer 160 keyboard (or passed to the replica computer by host 104 for execution via a "PC Execution" command for example) will be executed by the replica computer processor 68 if the "processor flag" at the replica computer is set to "replica computer"; and such commands will be executed by the customer computer 50 if the "processor flag" at the replica computer is set to "customer computer." In the preferred embodiment, the states of the customer computer and replica computer "processor flags" are initially determined by a default value (e.g., stored in a non-volatile table from the last session and/or as part of a default configuration). The "processor flag" can be dynamically changed by executing a program from a read only virtual disk provided by the host computer 104 (this allows the host computer to override a previously established processor flag state to ensure that a subsequent command is executed in a desired one of the customer and replica processors). The "processor flag" may also be changed when the user of customer computer 50 (or replica computer 160) changes his "command prompt." In DOS for personal computers, each "command line" is preceded by a "command prompt" specifying one of plural drives to be accessed by the personal computer. When a DOS operating system command is inputted on the command line, the drive specified by the command prompt is accessed first to locate an executable file that meets the description of the inputted command (in the absence of a "PATH" command, this is the only drive that will be looked to). The user can change the default drive by simply typing the designation of the drive to which the default drive is to be changed. For example, if the command prompt "C>" is displayed, the user can change the default drive from the "C" drive (e.g., the local hard drive) to an "E" drive (e.g., a virtual disk supplied by the replica computer) by simply typing "E:" and pressing the ENTER key. The preferred embodiment uses this specified prompt to optionally change the "processor flag" to the one of customer computer 50 and replica computer 160 corresponding to the newly selected default drive designator. Thus, for example, a customer computer 50 user can deselect local processing and instead select processing by the processor of replica computer 160 by simply changing his command prompt in the preferred embodiment from a local drive (e.g., "C>") to a virtual drive (e.g., "E>"). Similarly, for example, a customer computer 50 user can deselect replica processing and instead select local processing by the processor 68 of customer computer 50 by simply changing his command prompt in the preferred embodiment from a virtual drive (e.g., "E>") to a local drive (e.g., "C>"). The preferred embodiment also uses a technique called "drive translation" to automatically translate drive designators. Typically, commands inputted by a user of customer computer 50 will specify one or more drive designators (e.g., "COPY A:*.* C:" commands the computer to copy all files within a particular portion of a drive called "A" to a particular portion of another drive called "C"). Because any command can execute on either the customer computer 50 or the replica computer 160 in the preferred embodiment, an ambiguity exists since the same physical drive assignments may exist at each computer (e.g., the customer computer and the replica computer may each have their local floppy diskette drive assigned as "A" and their local hard drive assigned as "C"). Drive translation provides the ability to dynamically reassign a local drive designator. For example, with drive translation off, if the user of customer computer 50 issues the command "COPY A:*.* C:" (for example) with the processor flag set to "customer computer", this will have the effect of copying information from the customer computer ("A") local floppy diskette drive 60 to the customer computer ("C") local hard drive 64. On the other hand, if the user of customer computer 50 issues the command "COPY A.*.* C:" with drive translation on, the command is translated into a new command in which the drive designators "A" and "C" are replaced with different values, e.g., "D" and "F", specified by a mapping (e.g., stored in a "drive translation table" for each processor flag in the customer computer). This mapping typically maps local customer drive designators into "equivalent" virtual drive designators accessed by the replica computer 160 (e.g., the customer computer floppy drive designator maps into the drive designator the replica computer uses to access the customer floppy drive as a virtual drive). Drive translation is performed in the preferred embodiment on the computer that originates the commands, and not on the computer which receives the commands remotely (host "PC Execution" commands are considered local to the replica computer). This feature of automatically translating drive designators based on certain default machine selections facilitates a user's ability to conveniently and easily access desired drives of a "virtual machine" without unduly interfering with the user's ability to access the drives associated with his customer computer 50 "physical machine." In the preferred embodiment, the drive translation tables maintained by customer computer 50 and replica computer 160 for commands executed remotely are oppositely symmetrical. That is, the drive translation table entry for customer computer 50 remote processing is the (reversed) mirror image of the drive translation table entry for the replica computer 160 remote processing. Thus, in the preferred embodiment, when each of customer computer 50 and replica computer 160 assigns ("appends") drive designators to virtual drives provided by the other computer, it (the assigning computer) sends a list of its assignments to the other computer--and vice versa. As an example, if the customer computer 50 drive translation table entry for remote processing is set as: A.fwdarw.J B.fwdarw.K C.fwdarw.L X.fwdarw.A Y.fwdarw.B Z.fwdarw.C then the replica computer 160 drive translation table entry for remote processing may be set as: J.fwdarw.A K.fwdarw.B L.fwdarw.C A.fwdarw.X B.fwdarw.Y C.fwdarw.Z. Using these drive translation tables, with a command "COPY A:*.* C:" is issued by the customer computer 50 with the processor flag set to "customer computer" and with drive translation off, the command is executed by copying from the customer's local floppy diskette drive ("A") to the customer's hard drive ("C"). When the same command is issued by the customer computer 50 with drive translation on, it is translated into "COPY J:*.* L:". If this translated command is executed by the replica computer 160 (which accesses the customer's floppy diskette drive and customer's hard drive as virtual drives "J" and "L"), it will copy from the customer's local floppy diskette drive ("A") to the customer's hard drive ("C")--thus achieving the same result without the user of customer computer 50 having to know or use the drive designators that the replica computer must use in order to access the customer computer drives as virtual drives. FIG. 5 provides an overview of an example of the virtual disk drive attachment capabilities of the on-line service system 100. Two physical disk drives 116a, 116b are shown connected to the host computer 104. The host computer 104 is shown as a customer disk repository with host system disks 116a, 116b logically divided into customer virtual disks. Host computer physical disk drive 116a stores information associated with two different virtual disks (I:Drive and J:Drive), and host computer physical disk drive 116b stores information associated with a further virtual disk (K:Drive). The host computer 104 is shown with a communication link to the replica server computer 160 and a customer computer 50a. Two columns of drives shown within customer computer 50a identify the devices addressable by the customer processor. The first column, "Local Disk Drives," identifies the physical drives 64AA-64AC physically attached to the customer computer 50a. The second column, "Virtual Disk Drives," identifies the disk drives 136(1)-136(3) created from logically divided host storage (this may be the same or different storage is used to create virtual disk drives 136I-136K). Three columns of drives shown within the replica computer 160 identify the devices addressable by the replica computer. The first column, "Local Disk Drives," identifies the drives 164A-164C physically attached to the replica computer (A:Drive, B:Drive, C:Drive). The second column, "Customer Disk Drives," identifies the disk drives 64BD-64BF physically attached to the customer computer 50 that have been redirected to the replica computer 160 as remote virtual disks (D:Drive, E:Drive, F:Drive) (these may be the customer computer A:Drive, B:Drive, C:Drive)). The third column, "Virtual Disk Drives," identifies disk drives 136I-136K created from logically divided storage of host computer 104. Although each column shows three drives, this is not meant to limit the number of attachable devices. The replica computer 160 is shown with a communication link 166 to the host computer and another communication link 150b to a customer computer. Note that both the customer computer 50b and the replica computer 160 each access their local, physical disk drives as "A," "B" and "C." However, in the preferred embodiment the customer computer 50b accesses the replica computer 160's local drives as "D," "E" and "F," whereas the replica computer 160 accesses the customer computer 50b's local drives as "D," "E" and "F." This ability to "redirect" drives and "append" them to the nominal "drive list" of each computer provides a seamless, transparent interface to the virtual drives of the other computer without interfering with accessing local, physically attached disk drives in the same manner that they are normally accessed. Since all drives for both systems are directly available to both systems and local drives for both systems are already assigned (and it is undesirable to change the drive designators on local drives because they are already well known), each system has different drive designators (A: B: C:) to represent the same physical device. When a command is identified as originating from the customer and the processor flag is set to "replica computer" and customer command line translation is "yes," drive references on the command line are translated to their equivalent in the replica, i.e., a command at prompt C: of "copy A: B:" is same as (with command line translation) a command at prompt E: of "copy D: E:". Each computer needs to identify where commands actually originated, and also needs to keep track of where commands are supposed to execute. A "processor flag" maintained by each of the customer computer 50 and replica computer 160 is used to keep track of where commands are supposed to execute. The processor flag can optionally be set to replica or customer each time the default drive prompt is changed by the operating system. Thus, commands inputted by a user at the customer computer 50 when the customer's drive designator is set to a customer drive will execute in customer processor. Commands inputted by a user at the customer computer 50 when the customer's drive designator is set to a replica drive will execute in replica processor. The processor flag ultimately determines where a command will execute. If a user at the customer PC keys commands while the drive designator is set to customer drive, the commands will execute in the customer processor if the processor flag is set to customer. Similarly, when a user at the replica PC keys commands while set to customer drive, the commands execute in the customer processor if the processor flag is set to customer. When a user at the replica PC keys commands while set to replica drive, the commands execute in the replica processor if the processor flag is set to "replica computer." V. ON-LINE AND OFF-LINE TASK HANDLING FIG. 6A schematically shows some of the various connections provided by the preferred embodiment to attach virtual devices such as disks. In FIG. 6A, customer computer 50A is shown connected to host computer 104 with an on-line connection via data link 150a. Through this on-line connection and appropriate software executing on both customer computer 50A and host computer 104, a "virtual disk" made available by the host computer is "attached" to the customer computer. The customer computer 50A can read from and write to this "virtual disk" as if it were a physical disk locally attached to the customer computer. When the on-line connection between customer computer 50A and host computer 104 terminates, the information stored on the "virtual disk" continues to reside in the storage of host computer 104. This information can be made available to the same or different customer computer 50A (or to a replica computer 160A, 160B) by reattaching the "virtual disk" to that computer. FIG. 6A also shows an on-line replica computer 160A connected to host computer 104 via a local data link 161A (e.g., a coaxial "twinax" line or twisted pair cable). As explained above, on-line replica computer 160A can (and preferably does) have its own local hard disk(s), memory, and peripheral devices. In addition, on-line replica computer 160A and an on-line customer computer 50 in the preferred embodiment runs "workstation emulation" and "PC Support" software that allows it to attach locally to, and communicate with, host computer 104. The workstation session control program is specified as the sign-on program in the customer user profile on the AS/400. The profile is configured to sign-off the workstation when the control program ends. This program displays menu options and allows certain command input. Customer commands and menu requests are received and validated. Upon validation, commands and programs are executed by calls to system programs such as QUSCMDLN or QCMDEXC. These commands may include commands to cause execution in the personal computer processor. This PC execution may include running a secondary command processor (Command.Com) to provide the customer or replica computer user with a personal computer command prompt. This secondary command processor is ended with control returned to the caller when "Exit" is keyed. On-line replica computer 160A can attach to virtual disks made available by host computer 104 so that it can read from and write to the virtual disks. Replica computer 160A can also access other virtual devices (e.g., printers, etc.) made available to it by host computer 104. As shown in FIG. 6A, a customer computer 50B can have an on-line connection (via data link 150b) with on-line replica 160A. Through this on-line connection, on-line replica computer 160A can "attach" some or all of its resources (including those made available to the replica computer by host computer 104) to customer computer 50B. For example, on-line replica computer 160A can remotely attach some or all of its own local disk drives to customer computer 50B. On-line replica computer 160A can also remotely attach to customer computer 50B some or all of its virtual disk drives (e.g., RAM disks and/or virtual disks made available by host computer 104). In addition, on-line replica computer 160A can remotely attach to and access the local drives of customer computer 50B as virtual disk drives. As explained above, the way drives are remotely attached and shared between customer computer 50B and on-line replica computer 160A provides a seamless interface allowing a user of either computer to easily access the information stored by the other computer without having to perform file transfers or other complicated processes. FIG. 6A also shows an off-line replica computer 160B connected to host computer 104 via a local data link 161B (e.g., a coaxial "twinax" line or twisted pair cable). In the preferred embodiment, off-line replica computer 160B runs appropriate software that cooperates with the software running on host computer 104 to allow the off-line replica computer to access host virtual devices such as disk drives and the like. Off-line replica counter 160B performs processing requests made by host computer 104 (e.g., in response to service requests made by customer computers 50A, 50B) without requiring an on-line connection with a customer computer. The results of the processing by off-line replica computer 160B are reported back to host computer 104, which may then "signal" the appropriate customer computer 50 in order to report the results. FIG. 6B schematically shows the "signal customer processing" performed by system 100. In the preferred embodiment, system 100 sometimes needs to report completed results of "off-line" processing requests to a customer computer 50. In addition, system 100 occasionally has a need to automatically establish contact with a customer computer 50 (e.g., to perform a regularly scheduled backup or software update operation). Also, system 100 may have messages or information from other users (e.g., electronic mail) that it needs to deliver to a customer computer 50. Instead of waiting until the user of customer computer 50 decides to initiate an on-line session with system 100, in the preferred embodiment system 100 is able to initiate a contact with a customer computer it needs to contact. In the preferred embodiment, system 100 initiates such a communication by "signalling" the specified customer computer 50. This signalling can be a request for the customer computer 50 to call system 100, or the signalling itself can provide the transfer of information that is needed (e.g., system 100 can "signal" a customer computer 50 with a "completion message" indicating that a particular processing task has been completed). As shown in FIG. 6B, such "signalling" can occur through a "signalling" connection between customer computer 50A and host computer 104, or it can occur via a "signalling" connection between a customer computer 50B and a replica computer 160. In the preferred embodiment, such "signalling" connections are not true "on-line" connections because there is no ability for the user of customer computer 50 to interact with system 100. Rather, for security and other reasons, a true-on-line connection (which may occur automatically in response to the signalling contact from the host) is established subsequently to the signalling connection and is initiated by the customer computer 50. Preferably requiring on-line connections to be initiated by customer computer 50 in the preferred embodiment increases security and also may make the customer feel better about security (since typically a great deal of very sensitive data may be stored on the customer computer). FIG. 6C schematically shows, in generic terms, the different functions performed by system 100 associated with on-line service requests. As shown in FIG. 6C, an on-line service request can be performed by customer computer 50, on-line replica computer 160, or host computer 104. The results of such on-line service processing may comprise any one of the following: logging; generation of a host computer request; generation of an off-line request for handling by off-line replica computer 160; and/or generation of a signal request. FIG. 6D schematically shows, in generic terms, the different functions performed by system 100 associated with off-line service requests. As shown in FIG. 6D, an off-line service request can be performed by off-line replica computer 160 or host computer 104 in the preferred embodiment. The results of such off-line service processing may comprise any one of the following: logging; generation of a host computer request; generation of an off-line request for handling by off-line replica computer 160; and/or generation of a signal request. FIG. 6E schematically shows some of the more important high level tasks performed by each of the main components within the preferred embodiment (i.e., customer computer 50, host computer 100, and replica computer 160). Each of these tasks are performed under software control, and certain of these tasks may communicate with other tasks being performed by other components. The customer computer 50 in the preferred embodiment supports the high-level functions of communications, logging, security, routing, program execution, local disk access, and remote disk access. The on-line service host computer 104 support communications, logging, security, command control, program execution, host disk access and virtual disk access. The on-line and off-line replica computers 160 in the preferred embodiment each support communications, logging, security, routing, program execution, local disk access, and remote disk access. Each of the computers 50, 104 and 160 is provided with local physical mass storage disk. Thus, customer computer 50 has its local hard disk 64, host computer 104 has its local hard disk 116, and replica computer 160 has its local hard disk 164. FIG. 7, Customer On-line Service Control Process, provides an overview of on-line service control software executed within the customer computer 50. The customer computer 50 is shown in the center, surrounded by boxes representing various control processes. Clockwise from top left, block 300 describes Host/Replica Signal Control processing. The customer computer 50 tracks a signal pattern sent by the on-line service system. If a predetermined signal pattern match occurs, the customer computer 50 connects to the on-line service (without user ID and password) to receive an access code. This access code is used to determine the reason for access and default response (send message or trigger on-line session). A typical example would be for the on-line service 100 to send telephone ringing signals to the customers location. The customer computer 50 receives these ringing signals from the modem 80. The ringing signals are tracked and when a correct pattern is received, the customer computer 50 sends a modem command to switch to answer mode. The customer computer 50 then connects to the on-line service and receives an access code before disconnecting. Block 302 describes Host/Replica Session and Virtual Disk System software. This refers to software used to maintain an on-line session. Regardless of the type of link, communications software is needed to connect to the on-line service. When connecting directly to the on-line service host computer 104, device drivers are needed to provide session and virtual device support. When connecting to the on-line service with the replica server computer 160, device drivers are needed to provide replica server remote disk support. Block 304 references the redirected keyboard, timer, and communication interrupts. Keyboard interrupts are redirected for a number of purposes. Hot keys can be configured to activate the on-line service control program or to initiate an on-line service session. Automated session support is managed by storing script file data in the keyboard buffer upon matching video criteria or some other test (timeout, etc.). A replica server 160 on-line session requires redirection of keyboard and video interrupts to cause the customer computer 50 and replica server computer 160 to appear as one computer. The timer interrupt is redirected to allow on-line service sessions to be triggered when a specified date/time condition is met. The serial port interrupts are redirected to support the signal control process. Block 306 describes Replica Server On-line Session Control processes. These services are available to customers that wish to connect to the on-line service with an intermediate computer interfaced. The advantages are faster data transfer rates for some functions because the customer computer 50 and replica server computer 160 are of the same type; the ability to access a more powerful processor of the same type as the customer; the ability to access peripherals attached to the replica server that would otherwise be unavailable. One feature of the Replica Server On-line Session Control process (block 306) refers to the relation between the command prompt current drive and the processor for subsequent execution. When the customer computer 50 command prompt is set to a local customer disk drive 64, the next command is executed locally. When the customer computer 50 command prompt is set to a replica server remote disk 164, the next command is executed within the replica computer 160 with keyboard and video redirected to appear as if the command was locally executed. This includes translating drive designator references to replica system equivalents before sending a command to the replica keyboard buffer. The second feature in block 306 refers to configuration information sent between the customer computer 50 and replica server computer 160. Both the customer computer and replica computer 160 have access to drives of the other computer as remote virtual disks. Every time a drive is mounted on one system (including virtual disks mounted on the replica server 160), the drive needs to be configured (mounted) as a remote disk on the other computer. The Replica Server On-line Session Control process sends and receives configuration requests to cause drive mounts and dismounts on both computers. The third feature of block 306 refers to the management of I/O request for remote drive data. Since the remote drives can reside on either system, the router not only performs read/write requests on local disks for the replica processor, but also issues read/write requests for replica disk data for the customer processor. The last feature of block 306 refers to redirecting keyboard and mouse input and video and printer output. Block 308 describes Session Trigger Control. The reference is to service control programs chained into redirected interrupts. An on-line session can be triggered by keyboard input, a date/time or date/interval time, or by an access code received from the on-line service. The on-line service delivers this access code by sending a signal pattern to the customer computer 50 (pattern of telephone ringing signals). If the signal pattern matches, the customer computer 50 connects to the on-line service (command is issued to switch modem 80 to answer mode). Finally, the access code is received and the customer computer 50 disconnects. The block 310, On-line Session Control, describes the process of interactively accessing an on-line service with virtual disks. Since access is under control of the on-line service, the customer computer 50 needs to respond to certain requests such as user ID, password, and request option. The on-line service allocates resources and maintains billing information based on customer interaction. Block 312 describes the Automated Session Control process. Control programs are used to manage an on-line session without user information. Data is stored in the keyboard buffer when required. Various actions take place based on predetermined events (i.e., perform a function based on video buffer contents, or perform a function based on a timeout condition). Block 314 describes the Customer Security program. This program is used to validate requests for disk access and disable unauthorized copying of data stored in the customer computer RAM. The main purpose is to prevent customers from copying data and programs accessed on mounted virtual disks, particularly execute only software and rental information. VI. HOST PROCESSOR TASKS FIG. 8A offers an overview of on-line service control software executed within the on-line service host processor. Block 400 shows the On-line Service Customer Signup Process. Access is provided by dialing a special charge telephone number (block 400A). A message is displayed describing the services and charges for signup, and the amount of time left to exit before a signup charge is issued (block 400B). If the customer stays connected and responds to signup information, a user ID/password is assigned, software and control information is downloaded to the customer computer 50, and customer control information is stored on the host system 100 (block 400C). This control process can be performed by the on-line service computer 104 or the replica server computer 160. The latter is preferable because the link to the signup computer can be performed with standard communications software. Block 402 describes the Host Security Program. This program is used to validate access requests for virtual disks. Host system security provides secured access to control unauthorized virtual disk mounts. Host system security also controls virtual disks access as read-only or read/write devices. The Host Security program is used to control customer or replica server computer execution and copy access to virtual disk data. All requests for virtual disk data and programs are validated (blocks 402A, 402B). It should be noted that a similar validation program resides in the host computer 104, the replica server computer 160 (if used), and the customer computer 50. The customer computer 50 and replica server computer 160 use a modified version of this function with code to prevent unauthorized access to virtual disk data and programs resulting in RAM. Block 404 is the main control process for customer access. The Interactive Customer Session Control Process is used to manage the on-line session. Activities are initiated under control of this process. Session information is tracked for billing and security. Customer and host requests are managed by this process. If a Host Request Data entry is found for the customer, and the date/time condition is met (block 404C), and the request is not for off-line replica processing, the host request is processed by the customer on-line session as if the customer had issued it directly (block 404C). the Session Control Process also allows commands to be directed to an off-line replica computer for later execution (block 404D). Parameters and script file data is stored along with a date/time to perform the request. For interactive requests, the Begin Process Request (block 404E) performs the request. Block 406 describes the Off-line Replica Request Control process. This process is somewhat similar to the Interactive Customer Session Control Process except that no user interaction occurs. Requests are read from the Replica Request Data (block 406B). If the date/time condition is met, then Customer Control Data (block 406C) is accessed and interrupts are redirected to manage the request using script file data available from the Replica Request. The Begin Process Request (block 406E) function is then called to perform the actual request. An off-line replica computer 160 connects to the host 104 with a special user ID. This user ID provides access to customer disks used for routing files, and provides access to on-line service programs stored on virtual disks. Block 408 describes the Host Request Task Control Process. The purpose of this control process is to generate requests for the off-line replica computer 160, and to signal a customer to establish an on-line session. Host Request Data is read (block 408A), and if the date/time condition is met, the Customer Control Data is read (block 408B). If the customer computer is connected to the on-line service, the request is bypassed. The Host Request Notify Method field determines if the customer should be signalled before the request is performed (block 408C). If so, Signal Customer Data is written for the customer. If the request is for off-line processing, a Replica Request is written for the customer block (block 408D). Block 410 describes the Signal Customer Task Control Process. This process can execute in the host computer 104 or the off-line replica computer 160. Signal Customer Data is read (block 410A). When the date/time condition is met, Customer Control Data for the customer is read (block 410B). If the customer is signed on, a host request is issued. Otherwise, the Signal Customer Data Access Code is used to get a signal pattern stored on the Customer Control Data. This signal pattern (pattern of telephone rings) is then sent to the customer computer (block 410D). If the customer computer answers at the correct time, the access code is transmitted to the customer computer. If the access code is used to trigger at on-line session, then the sign-on allowed flag on the Customer Control Data is updated to allow sign-on without dialback. FIG. 8B shows the Begin Process Request routine shown in FIG. 8A with an expanded view by type of service. As shown in FIG. 8A, blocks 404D and 406D each obtain a request to be processed and pass that request to the "begin process request" block (404E, 406E). The request is process by host computer 104 and/or replica computer 160, depending on the request. The host computer 104 and on-line replica computer 160 each execute different software, but in the preferred embodiment each can perform all of the functions shown in FIG. 8B (some of the functions are, however, performed differently depending on whether the host or the replica performs them). If the request is for "backup, restore and archive" services, host computer 104 logs certain information (e.g., user, begin time, etc.) for billing and security purposes (block 414), and then allocates ("mounts") the appropriate virtual disks containing the software needed to satisfy the request (block 416). The process of copying the information is performed in the preferred embodiment by customer computer 50 and/or replica computer 160 by copying information to and/or from a virtual disk (block 418). The end time is preferably then logged by host computer 104 for billing purposes (block 414). If the request is for anti-viral scan (block 420), the request is logged (block 422) and a read-only virtual disk storing anti-viral software is then attached to the appropriate computer (e.g., customer computer 50) (block 424). The anti-viral software is then executed in the customer computer 50 and/or replica computer 160 as appropriate (block 426). If the request is for program or data rental (block 428), the appropriate information is logged as before (block 430), and the virtual disk storing the program or data to be rented is then allocated to the appropriate computer (e.g., customer computer 50 and/or replica computer 160) (block 432). A "host" security program is executed by the host computer 104 to prevent unauthorized copying of the virtual disk contents, and a similar program executes in the customer computer 50 and replica computer 160 to prevent unauthorized access to virtual disk data and programs residing in random access memory. The customer computer 50 and/or replica computer 160 executes the rental program or accesses the data (block 434). Meanwhile, host computer 104 keeps track of beginning and ending times of access to ensure that the customer can be billed based on the amount of time he has used the contents of the virtual disk (block 430). A customer can also be billed on a per basis or a monthly charge basis. In the preferred embodiment, the user may request to "purchase" a particular program or data. For example, the user may want his own copy of the program or data locally stored or he may wish to modify it such that it is not feasible to merely rent it. If the request is for a "purchase," logging is performed as before (block 438), and then the host computer 104 allocates the appropriate virtual disk containing the program or information to be purchased (block 440). Host computer 104 also allocates a destination device for receiving the purchased program or information (block 442). This destination device may be, for example, the local hard disk 64 within customer computer 50. The selected software is then copied to the destination device in order to complete the purchase (block 444). This copying operation is preferably performed only upon receipt of payment from the customer (e.g., by checking credit card authorization and charging the associated license fee to the customer's credit card account). Software demonstrations of the programs not requiring secured customer data can be made available to all customers by providing access to a shared, execute-only virtual disk. Demos allowing secured customer data can be provided by copying programs or information stored on a secured virtual disk to a temporary virtual disk with customer execute-only access. If payment is not received within a specified period, the virtual disk can be deleted. Upon receipt of payment, the temporary virtual disk ownership can be transferred to the customer for complete access. This enables the customer to obtain immediate access to the desired software while allowing the service provider to later revoke access if payment is not received. If the request is for release update services (block 446), the request is logged as before (block 448), and host computer 104 also determines whether the customer is entitled to release update and also whether this particular customer wants or needs the release update (block 450). Assuming that the customer is authorized to receive, wants and needs the update, host computer 104 allocates a virtual disk storing the release update (more than one may be transferred at the same time) (block 452), and then copies and/or applies the updates to customer computer 50 (block 454). When necessary, a program can be executed to perform special services such as configuration changes to customer computer 50. Blocks 456-462 provide a generic description of additional user request handling. Beginning and ending times are logged for billing and security (block 458), appropriate virtual disks and/or other virtual devices are allocated to handle the request (block 460), and appropriate software is executed and data is accessed within host computer 104 and/or replica computer 160 and/or customer computer 50 to handle the request (block 462). VII. REPLICA COMPUTER TASKS FIG. 9, Customer Replica Control Process, provides an overview of service control software executed within the on-line and off-line replica computers 160. The replica computer 160 is shown schematically in the center, surrounded by blocks representing various control processes. Block 470 describes the Customer Signal Process. This process can also be executed by the host computer. Ringing patterns are sent to a customer computer 50 to cause a monitor control program to change the customer modem 80 to answer mode (block 472). When the customer modem 80 answers, an access code is transmitted to the customer computer 50. This access code is used to trigger an on-line session or send a message to the customer computer 50. Block 474 refers to host session and virtual disk system software needed to maintain an on-line session with virtual devices. This software consists of device drivers and workstation emulation software. Block 476 describes the Customer Session Control process. This communications software is used to connect the customer computer 50 to the replica service computer 160. The replica server modem 162 is set to answer mode, while a customer connection is awaited. Upon connection, the host sign-on display is redirected to the customer computer 50. Customer sign-on information redirected to the replica server keyboard buffer is passed to the host computer 104 (block 478). The Replica Server Router Control Process is described in blocks 480-488. Since drives for both systems are remote to each other, the Router Control process is needed to manage I/O data requests, drive configuration requests, execution requests, and keyboard, mouse, video and printer redirection requests. Block 490 describes the Off-line Session Control processing performed by an off-line replica computer. Replica Request Data is read and requests are performed without a customer connection (block 492). When the request is created, parameters and script file data are stored. The stored data is used by this process to satisfy the request. Block 494 describes the On-line Session Control. Customer keyboard input redirected to the replica server keyboard buffer are received by workstation emulation software and passed to the host computer (block 496). The host computer issues requests to execute software within the replica server processor during an on-line session. Block 498 describes Automated Session Control. This process is used to provide keyboard input to manage a request without user intervention. Parameters and script file data are moved to the keyboard buffer with a control program linked by interrupt chain (block 500). Block 502 describes the Replica System program. This program is used to validate requests for disk access and disable unauthorized copying of data stored in the replica server computer RAM. The main purpose is to prevent customers from copying data and programs accessed on mounted virtual disks, particularly execute only software and rental information. VIII. DETAILED DESCRIPTION OF CUSTOMER COMPUTER TASKS AND DATA STRUCTURES FIG. 10 is a flowchart of exemplary program control steps performed by customer computer 50 in the preferred embodiment in order to interact with on-line service system 100. The steps shown in FIG. 10 can be performed by customer computer 50 with the "CONFIG.SYS" and "AUTOEXEC.BAT" files in a DOS environment or then can be performed with a batch file on request. In any event, the preferred embodiment, device drivers are loaded into customer computer memory 66 to support the virtual device "PC SUPPORT" facility of host computer 104 or to support remote access to the on-line replica computer 160. When customer computer 50 is first turned on or "booted," (block 502), it first loads an on-line service control data table into its memory 66 (block 504). An exemplary format for this on-line service control data table 501 is shown in FIG. 16A. This data table 501 in a preferred embodiment contains the following information: On-line Service Control Data Table 501 Hardware Configuration Data 600 Basic information on the type of computer used by customer. Customer Profile Data 602 Standard Customer Information used to sign on and identify the customer. Host Signalling Parameters 604 Table Occurs, Host Access Code, Host Phone No., Host reason, Response Default For each host signal access code, there is an associated on-line service phone number, reason for being signalled, and default response for the customer. Host reasons include: Dialback request, route request, option complete, replica complete. Response defaults include: Immediate dialback, set interval time, display message. Other host reasons and response defaults can be created. Session Active Flag 606 Indicates an on-line session is active. Host/Replica Session 607 Indicates whether the customer is connected directly to the host or replica. Automated Session Flag 608 An on-line session with automated keystrokes. Service Control Program Hot Key 610 Accesses the control program to display and change service options and configuration data. On-line Service Session Initiation Hot Key 612 Can be used to start an on-line Session (session can also be started by timer or signal from on-line service). Command Prompt Drive Change Hot Key 613 Can be used to change to a different command prompt (and possibly different processor). Redirected Interrupt Table Occurs 614 Used to maintain the status of interrupt routines that have been redirected for on-line service functions. Automated Session Table Occurs 616 Four variable length tables can exist--by date/time, day/time, date/interval period, and day/interval period. For each table entry, service options can be stored for automatic processing. Ringing Pattern Stores Table Occurs 624 The dialing patterns the on-line service can send to the customer are stored. When a pattern match occurs, the customers modem switches to answer mode and receives an access code from the host to determine why the on-line service sent a signal. Wait time is used to calculate the time till the next call in the pattern. Tolerance allows for fuzzy logic for number of rings (i.e., + or -2 rings on calls) or interval period between calls (i.e., + or -15 seconds). Backup Parameters 626 Backup Option Flag, Incremental Flag, Full Backup, Backup File List The backup option flag is used to indicate a backup request. Backup can be incremental, full backup or based on a file list. File list includes target location information. Restore Parameters 628 Restore Option Flag, Incremental Flag, Full Restore, Restore File List Same as backup list above except files are restored from the on-line service. Data may be on Virtual Device or Archived to tape or other media. Anti-Viral Parameters 630 Anti-viral Option Flag, Device Cleansing List, Build Anti-Viral Environment Indicates a request for Anti-Viral Services. The device cleansing list identifies drives, subdirectories, and | ||||||