United States Patent
`US 6,477,624 B1
`(10) Patent No.:
`(12)
`Kedem etal.
`(45) Date of Patent:
`Nov. 5, 2002
`
`
`US006477624B1
`
`(54) DATA IMAGE MANAGEMENTVIA
`tevin OF NON-VOLATILE STORAGE
`
`(75)
`
`Inventors: Zvi M. Kedem; Davi Geiger;
`Salvatore Paxia; Arash Baratloo;
`Peter Wyckoff, all of New York, NY
`(US)
`C5) Asana: Ondotek IneEden, N1(US)
`(*) Notice:
`Suemflo vey aisclaimer, the formorhs
`:
`:
`:
`SC. ‘T54(b)by O days. ee une
`
`*
`
`.
`
`:
`
`(60)
`
`(21) Appl. No.: 09/690,058
`(22)
`Filed:
`Oct. 16, 2000
`Related U.S. Application Data
`Provisional application No. 60/163,954, filed on Nov. 8,
`1999, provisional application No. 60/211,291, filed on Jun.
`13, 2000, and provisional application No. 60/240,138,filed
`on Oct. 13, 2000.
`Int. Ch? G06F 13/368; GOGF 13/16
`(1)
`(52) U.S. Che eecsecccsseeeessseees 711/147; 711/130; 709/216;
`714/29
`(58) Field of Search ....c..cccccccssccssssees 714/29; 711/1,
`711/6, 118, 162, 165, 202, 130, 124, 147;
`709/216, 219
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`5,819,065 A * 10/1998 Chilton et al. oo. 703/24
`5,896,322 A *
`4/1999 Ishii we .
`5,963,971 A * 10/1999 Fosler etal. ...
`5,991,542 A * 11/1999 Han et al. wo... TAT/167
`
`
`
`2/2001 Day, Wletal oo... 707/205
`
`6,185,580 B1 *
`* cited by examiner
`Primary Examiner—B. James Peikari
`(74) Attorney, Agent, or Firm—Rothwell, Figg, Ermst &
`Manbeck
`
`(57)
`ABSTRACT
`‘haemanageeeDIM)haie
`(RPSD), the DIM communicateswith the RDIM through
`manager
`(RDIM), and a remote
`persistent storage device
`a direct communication link or through a communication
`network. ‘(he RDIM can store data on andretrieve data from
`the RPSD. In an environment where an LDIM has been
`installed in a computer having a “local” persistent storage
`cowie (FSD), the pisews roroeforing of the
`*s
`data image on the
`, with
`the
`serving as
`a persistent, consistent cache of the data image. The data
`image stored on the RPSDis referred to as the “master data
`image” and the data image cached on the LPSDis referred
`to as the “local data image” or “cached data image.” The
`LDIM functions to intercept read/write requests that are
`intended to be received by the T.PSD. The read/write
`requests specify an address of the LPSD. Uponintercepting
`a read request,
`the LDIM is programmed to determine
`Whether the portion of the cached data image that is stored
`at the specified address is up-to-date. If it is up-to-date, the
`LDIM retrieves the requested data from the LPSD and
`passes the data back to the componentor device from which
`it received the request. If it is not up-to-date, the LDIM
`transmits the read request to the RDIM. Uponreceiving the
`read request, the RDIM locates and reads the requested data
`from the master data image stored on the RPSD and then
`transmits the data back to the LDIM.
`
`47 Claims, 9 Drawing Sheets
`
`LDIM
`
`202
`[
`
`407
`
`409
`
`ETHERNET
`CONTROLLER
`
`FLASH
`RAM
`
`
`
`408 CONTROL 410
` QUAL PORTED
` 4OI—N
`
`
`ao
`
`420
`
`CONNECTOR
`
`460
`
`
`
`ETHERNET CONNECTOR
`
`
`
`
`
`CONNECTOR
`
`
`
`RAM 2
`
`BUFFER
`
`
`HOST IDE CONNECTOR
`
`
`
`
`
`
`
`UNIT
`
`
`HARD DISK
`
`(SECONDARY
`
`406
`STORAGE)
`
`
`
`411
`
`7
`
`
`
`Google Exhibit 1091
`Google v. VirtaMove
`
`Google Exhibit 1091
`Google v. VirtaMove
`
`

`

`U.S. Patent
`
`Nov.5, 2002
`
`Sheet 1 of 9
`
`US 6,477,624 B1
`
`100
`
`

`

`U.S. Patent
`
`Nov.5, 2002
`
`Sheet 2 of 9
`
`US 6,477,624 B1
`
`v0Z
`
`O12
`
`Cols
`
`JIN
`
`001
`
`901
`
`

`

`U.S. Patent
`
`Nov.5, 2002
`
`Sheet 3 of 9
`
`US 6,477,624 B1
`
`100
`
`CPU
`
`DA
`
`306
`
`302
`
`303
`
`304
`
`/
`
`ZN
`
`TO
`
`NETWORK
`210
`
`“7
`302(a)
`Y
`308
`PROCESSOR/LOGIC CIRCUITS 4 4
`
`
`
`& MEMORY
`
`312
`
`10
`
`302(b)
`
`Lk
`
`HARD DISK
`
`FIG.3
`
`

`

`U.S. Patent
`
`Nov.5, 2002
`
`Sheet 4 of 9
`
`US 6,477,624 B1
`
`807
`
`(30vYOIS
`
`OlyTOULNOD
`
`oe_LyGOPOvY
`
`
`wavanoaas)|°°7ua4ing|¥SICO’UVH
`uaLdvavWs
`innYOLONNO9
`cO¥YOLOINNOO
`
`
`
`
`HSV14JANY3SH
`
`WdYATIONLNOD
`
`
`
`Q31HOd‘Wid
`
`|WY
`
`C3i40dwna
`
`3d1_1SOH
`
`YOLOANNOD
`
`LOv
`
`OCP
`
`094
`
`
`
`
`
`
`

`

`U.S. Patent
`
`YalSI93y
`
`Gv
`
`Sheet 5 of 9
`
`US 6,477,624 B1
`
`Nov.5, 2002
`
`fUWLS
`
`

`

`U.S. Patent
`
`Nov.5, 2002
`
`Sheet 6 of 9
`
`US 6,477,624 B1
`
`SUSNVaVd
`
`avi
`
`ALUM
`
`YOLOSS
`
`SUMASGuWaT0
`
`SNLVISMt:ON
`
`avs
`
`Ol
`
`SaANSALVISLYaSSV
`qooul
`
`
`
`ON
`
`ALEM
`
`SNIWLS
`
`ALNOAXA
`
`GNVNNOO
`
`SYSNVeVdLig
`
`Ll
`
`ASA14S34
`
`Ou1S
`
`
`
`SAWSsay]eV
`
`dvauul
`
`ON
`
`ON
`
`ALUM
`
`Oud
`
`SNLWIS
`
`
`
`
`
`

`

`U.S. Patent
`
`Nov.5, 2002
`
`Sheet 7 of 9
`
`US 6,477,624 B1
`
`HOST COMPUTER Pl COMMANDS
`
`CSTART
`
`WRITE
`PARAMETERS
`
`WRITE
`COMMAND
`OPCODE
`
`NO
`
`
`
`
`
`
`STATUS
`BUFFER
`
`INTERRUPT
`
`YES
`
` READ
`
` READ
`
`
`
`

`

`U.S. Patent
`
`Nov.5, 2002
`
`Sheet 8 of 9
`
`US 6,477,624 B1
`
`HOST COMPUTER PO COMMANDS
`
`(stant
`
`log]|g_|
`
`WRITE
`COMMAND
`OPCODE
`
`WRITE,
`PARAMETERS
`
`NO
`
`SET/
`BUFFER||
`
`DRQ
`
`ES
`
`WRITE
`
`NO
`
`Jr
`
`INTERRUPT
`
`YES
`
`()]i END
`
`FIG./
`
`READ
`STATUS
`
`

`

`U.S. Patent
`
`Nov.5, 2002
`
`Sheet 9 of 9
`
`US 6,477,624 B1
`
`HOST COMPUTER ND COMMANDS
`
`PARAMETERS
`
`WRITE
`COMMAND
`OPCODE
`
`
`
`
`
`
`NO
`
`<NTERRUPT
`
`
`
`YES
`
`READ
`STATUS
`
`

`

`US 6,477,624 Bl
`
`1
`DATA IMAGE MANAGEMENT VIA
`EMULATION OF NON-VOLATILE STORAGE
`DEVICE
`
`This application claims the benefit of the following three
`U.S. Provisional Patent Applications: (1) U.S. Provisional
`Patent Application No. 60/163,954,filed, Nov. 8, 1999; (2)
`US. Provisional Application No. 60/211,291, filed Jun. 13,
`2000; and (3) U.S. Provisional Application No. 60/240,138,
`filed Oct. 13, 2000, entitled “Computer System Providing a
`Virtual Disk Image Management System in Software.” All
`of the above mentioned provisional patent applications are
`incorporated herein in their entirety by this reference.
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`
`The present invention is generally related to persistent
`storage devices, and, more specifically,
`to a system and
`method for enabling the centralized storage and maintenance
`of persistent storage device data images.
`2. Discussion of the Background
`In general, the ability to store and access datais critical for
`computers. For example, when turned on, a computer(e.g.,
`a personal computer (“PC”)) accesses, and prepares (or
`“boots”)
`the operating system from its local persistent
`storage device (e.g., “hard disk”). Once the booting is
`finished, the contents of the hard disk are accessible and
`available to the user. The contents of the hard disk (also
`referred to as the hard disk’s “disk image”or “data image’)
`define the user’s personalized cnvironment: the opcrating
`system (such as Windows98 SR-2, Linux,etc.), the software
`applications (such as word processors, spreadsheet
`programs, web browsers, etc.),
`the data files (such as
`documents, spreadsheets, images, or cookies), and anyaddi-
`tional customization (such as whether a particular web
`browser, such as Netscape Navigator or Internet Explorer, is
`automatically launched when an HTMLfile is accessed).
`A hard disk is but one example of a persistent storage
`device. Apersistent storage device can be defined as follows:
`(a) it is a physical device that is physically attached to a
`computer using a standard physical interface (e.g., a
`hard disk attached with an IDE cable). This physical
`interface provides the link between the persistent stor-
`age device and the computer. (If the persistent storage
`device woder consideration is a hard disk, the physical
`interface is frequently called a connector and is typi-
`cally attached to a hardware component on the com-
`puter called the disk adapter, which itsclf provides the
`logical link between the persistent storage device and
`the computer);
`(b) it contains a local permanent medium(e.g., magnetic
`media)
`for storing a sequence of bits, (i.e., data),
`typically organized according to a particular file struc-
`ture. The bits are collectively called the persistent
`storage device data image (PSDDI), or data image (DI)
`for short. When the persistent storage device is a hard
`disk,
`the persistent storage device data image will
`frequently be called a “disk image.” Typically, the local
`permanent mediumis capable of storing a large amount
`of data (e.g., more than 10 Megabytes);
`(c) it has the ability to selectively read and write any part
`of the data image; and
`(d) it allows the computer to which the device is attached
`to selectively read and write anypart of the data image
`through a standard sct of interface protocols.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`55
`
`60
`
`65
`
`2
`The scope of persistent storage devices includes all hard
`disk drives implementing interfaces such as ST506/412,
`ESDI, SCSI, IDE, ATA, ATAPI, ATA-E and EIDE, read/
`write CD ROMdrives, ZIP drives, JAZ drives, floppy drives
`and the like. In addition, the present invention applies to
`embedded systems’ persistent storage devices, such as,
`Flash, and DiskOnChip.
`Any two “hardware-similar” PCs having the same data
`image would appear the same to the user. In contrast, if a
`user’s data imageis replaced by a significantly different data
`image, the user will most likely see an unfamiliar desktop
`displayed on the PC’s display screen. What would be even
`more disturbing and likely to make the PC unusable to the
`user, is the fact that the new data image would havedifferent
`software and data files from the original data image. Thus,
`it
`is the data image that makes a uscr’s PC the uscr’s
`“Personal Computer,” and it is the most valuable and essen-
`tially the only irreplaceable component of the PC.
`The conventional PC is “governed” by the contents ofits
`hard disk, and therefore the limits of the installed software
`becomethe limits of the user. Once the user’s needs change,
`or grow beyondthe capabilities of the installed software, the
`user has to deal with upgrading or installing a new OS or
`application software, a costly,
`time consuming, and fre-
`quently aggravating process even for a professional.
`Moreover,
`in environments such as offices within large
`companies or firms, this problem is compounded because
`the hard drive on each individual PC needsto be accessed in
`order to perform an upgrade. In addition, such upgrades may
`cause some exisling software not to work properly, in effect
`corrupting the previously stable data image.
`There are several computer architecture models that
`attempt
`to solve the above problem. These architecture
`models and their respective disadvantages are described
`below.
`Network Computer: A network computer (NC)is a light-
`weight computer with a simple built-in operating system.
`After booting,
`it connects to a remote computer for file
`system access. Software programs reside on the remote
`computer. Once invoked, they are downloaded to the NC
`where they execute. The applications are typically based on
`Java or JavaScript. The problems with an NC are that
`existing applications have to be re-engineered for
`this
`platform, and an NC has limited capability to perform
`computing operations when not connected to the network.If
`the software on the NC is badly corrupted, it may not be able
`to boot or access the network and therefore the NC will not
`be functional. Thus well
`functioning local software is
`required for operation. Further, NCs have no notion of
`providing a remote image to a local computertransparently
`to the operating system executing on the local computer.
`Thin Client: The local computer, termed the thin client, is
`used mainly for display and user input. Applications execute
`on a server andthe thin client opens a windowto the server
`to interact with the applications. For the thin client to work,
`a continuous connection fromthe thin client to the server is
`
`needed. A thin client is typically running on a standard
`computer; however,
`the thin client
`technology does not
`provide any meansfor remotely administering or upgrading
`of the computer’s software. In addition, thin client technol-
`ogy requires that the data files (such as Word documents) be
`manipulated on the server, which requires that they not be
`encrypted during such manipulation. Also, well functioning
`local software is required for operation. Thin clients are also
`operating system specific.
`Remote booting and Disk-less computers: Some operat-
`ing systems, such as Unix, MacOS and Windows 95 allow
`computers to boot from an image on a remote computer.
`
`

`

`US 6,477,624 Bl
`
`4
`address (for example, in the case where the LPSD includes
`a hard disk, the read/write requests specify a sector of the
`hard disk).
`Upon intercepting a read request, which specifies an
`address, the LDIM is programmed to determine whether the
`portion of the cached data image that
`is stored at
`the
`specified address is up-to-date (i.e., whether the portion of
`the cached data imagereflects the latest changes madeto the
`master data image).
`In one embodiment,
`this feature is
`implemented by having the LDIM request a “modified-list”
`from the RDIM each time the LDIM is powered on and
`(optionally) to have the RDIM provide to the LDIM updates
`to the modified list whenever a modification to the master
`
`10
`
`3
`This feature is typically used for disk-less computers.
`However, even if the computers have a disk drive or other
`persistent storage device, it is only used as a swap space
`(cuntime operating system scratch space), and the contents
`do not persist across boot sessions. Remote booting and
`diskless computers do not work off line.
`Remote File System Technologies: They allow mounting
`of a remote file system to a local computer (e.g., NFS).
`Remote file systems can be provided by a remote computer
`or by a remote network disk. These technologies allow a
`computer to access data and programs stored on remote
`server(s). However, system software built into the operating
`system is required. Remote file technologics do not allow
`remote administration of the computer. They also require
`functioning software on the computer. In addition, remote
`file system technologies do not work off line whilst the
`present invention does work off line.
`Automaticfile propagation: Software tools such as Unix’s
`rdist, allow files to be synchronized across networked com-
`puters; however, such tools are operating system and file
`system specific, and require a functioning operating system
`for them to work.
`
`Whatis desired is a system and/or method that overcomes
`these and other disadvantages of conventional computers
`and computer architectures.
`
`SUMMARYOF'THE INVENTION
`
`data image occurs. The “modified-list” is a list of all the
`“parts” or “portions” of the master data image that have been
`modified since the last time the LDIM was informed of
`modifications to the master data image. (For example, if the
`master data image is a data image from a hard disk,thelist
`of parts could be a list of the disk’s sectors.) Thus, if the
`LDIM receives a read request specifying an addressthat is
`on the modified list, the LDIM will knowthat the portion of
`the cached data image stored at the specified address is not
`up-to-date.
`If the LDIM determinesthat the cached data image has the
`most up to date version of the requested data, then the LDIM
`(1) retrieves the requested data from the LPSD byissuing a
`read request to the LPSD and (2) passes the retrieved data
`back to the component or device from whichit received the
`The present invention providesa persistent storage device
`request. If the cached data image does not have the most
`data image management system, or data image management
`update version of the requested data, then it must be stored
`system (DIMS) for short, that is able to solve the above
`on the RPSD (i.e., the master data image). In this case, the
`described problems that users encounter when upgrading
`TLDIMtransmits to the RDIMaread request message, which
`and/or maintaining their computers.
`may include the address specified in the intercepted read
`According to the present invention, the DIMS completely
`request. Upon receiving the read request message, the RDIM
`de-couples a persistent storage device data image “seen” by
`locates and reads the requested data from the master data
`the computer from a persistent storage device attached to the
`image stored on the RPSD and then transmits the data back
`computer (also referred to as the local persistent storage
`to the LDIM.
`device (LPSD)). The DIMSincludes a local data image
`manager (LDIM), whichis requiredto be installed (either by
`the manufacturer, the distributor, a user, or a technician) on
`the user’s computer, a remote data image manager (RDIM),
`and a remote persistent storage device (RPSD). The LDIM
`communicates with the RDIM through a direct communi-
`cation link or through a communication network (e.g., a
`local area network, a wide are network, the Internet, the
`public switched telephone network, a wireless network,etc).
`The RDIM can store data on and retrieve data from the
`RPSD.
`In an environment where an LDIM has beeninstalled in
`a computer having a “local” persistent storage device
`(LPSD), the DIMSallowsfor the storing of the LPSD’s data
`image on the RPSD, with the LPSD serving as a persistent,
`consistent cache of the data image. The data image stored on
`the RPSD is referred to as the “master data image” and the
`data image cached on the LPSDis referred to as the “local
`data image” or “cached data image.” In general, there is no
`requirement that the LPSD and the RPSD be of the same
`type. For instance, the LPSD could be a DiskOnChip and the
`RPSD could be a hard disk. Also,
`the RPSD may be a
`specialized smart device rather than being installed in a
`general purpose computer.
`The purpose of the LDIM is to imitate the LPSD. Thatis,
`the LDIM,from the computer’s perspective, appears exactly
`like the LPSD. More specifically, the LDIM functions to
`intercept and process requests that are intended to be
`received by the ILPSD, which maynotbe in factinstalled in
`the computcr. Commonare read/write requests specifying an
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Upon intercepting a write request, the LDIM may write
`the data to the LPSD, if there is one, and transmits the data
`to the RDIM so that the RDIM can update the master data
`image thereby ensuring that the master data image is up to
`date. The LDIM mayeither transmit the data to the RDIM
`substantially concurrently with writing the data to the LPSD
`or wait until some later time (e.g., if the computer is not
`currently connected to the network or if the network is
`heavily loaded).
`On requests other than read or write request, such as PND
`(Program Non Data request for IDE hard disks), the LDIM
`returns a response as required by the standard protocol for
`communicating with the LPSD.
`It is contemplated that in some embodimentsthere will be
`no LPSD. In this case, there is no cache as described above.
`Instead,all read/write requests for data that are received by
`the LDIMare transmitted to the RDIM. In the case of a read
`
`request, the RDIM retrieves the requested data and transmits
`the data back to the LDIM. In this manner, a user of the
`computer has access to his or her personalized data image
`even when the compuler is not equipped with a local hard
`disk or other persistent storage device. It is also contem-
`plated that to gain the greatest benefit from the invention the
`computer in which an LDIM isinstalled should, as often as
`is possible, be connected to a network so that the LDIM can
`communicate with an RDIM.
`
`limiting the scope of the
`From now, and without
`invention, the invention and its benefits will be described
`with respect to the particular embodiment where the LPSD
`
`

`

`US 6,477,624 Bl
`
`5
`is a hard disk. Once the DIMSisin place, the user need not
`concern him or herself with the task of upgrading his or her
`operating systems, application programs, data files, etc.,
`following setting the appropriate agreements with the orga-
`nization in charge of managing the master dala images on
`RPSDs. ‘This is because software patches and upgrades can
`be first performed on the master data image by an experi-
`enced system administrator. After the system administrator
`performs the upgrade on the master data image, the DIMS
`transparently ensures that these patches and upgrades are
`propagated to the local hard disk, as described above.
`Similarly, as described above,
`the DIMS automatically
`backs up all data files that are stored on the local hard disk
`that have been modified. This is accomplished by the LDIM
`transmitting the modified files (or scctors) to the RDIM so
`that the RDIM can update the master data image. In this
`manner, the master data image is kept up to date.
`Additionally, the DIMS can cache multiple master data
`images on the local hard disk. This is advantageous where
`the computer has more than one user and each userhas his
`or her own personalized data image. The DIMS uses a
`standard coherent caching algorithm (such as described in
`the standard textbook: Almasi and Gottlieb, Parallel
`Computing, 2"cdition, 1994, the entire contents of which
`are incorporated herein by this reference.) and implementa-
`tion to store the cached data images and maintain their
`coherency with the corresponding master data image. When
`the LDIM is unable to communicate with the RDIM,the
`computer in which it is installed can still operate to the
`extent that the required software and data is cached on the
`local hard disk.
`
`Preferably, the DIMS provides this functionality below
`the operating system and all of its components (including
`device drivers) and BIOSroutines specific to the hardware
`of the computer. Thus, the DIMSis completely transparent
`to the operating system andall applications of the computer.
`This allows the DIMSto be independent of any operating
`system or software installed on the computer. At the same
`time, it has the ability to provide the computer with any type
`of operating system compatible with the computer’s
`hardware, software, and other data.
`This enabling technology provides a rich gamut of func-
`tionality that completely changes the way computers are
`utilized. A user can use any “hardware compatible” com-
`puter as their “Personal Computer,” as the new computer
`transparently, without the user’s intervention, obtains over a
`networkonly those parts of the user’s data image needed for
`the current execution, with the other parts followinglater.
`Torinstance if the user wants to start execution by editing a
`document and then at a later point in time create and send an
`e-mail, a word processor will be downloaded before the
`e-mail program. A user’s computer can be replaced by a new
`one with the ease of “plug and play,” retaining all the user’s
`desired previous software, data, and settings. The user is
`presented with practically unlimited disk space, as the size
`of the master data image is not constrained by the size of a
`local disk.
`
`The software and data cached on the local disk provide
`instantaneously for the normal needs of the user,
`thus
`minimizing the network traffic between the location where
`the master copy is stored and an individual computer. As the
`user’s software does not execute remotely, data files are kept
`private through encryption-which can be done even on the
`local hard disk, with LDIM encrypting and decrypting the
`data as needed.
`
`The DIMSis easy to integrate into existing platforms,
`provides, for the first timc, a complete automated manage-
`
`10
`
`20
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`ment and administration capability in LANs and over the
`Internet, while maintaining fully the rich computer func-
`tionality. The DIMScreates the following benefits: increased
`user satisfaction and productivity, removal of the need for
`users to spend time on administration or wasting time
`waiting for somebody to repair the damage they may have
`caused to their local disk contents, and in general tremen-
`dous savings in both the explicit and implicit parts of total
`cost of ownership.
`In today’s computers, to access a hard disk, the following
`sequence of steps are performed:
`1. An application wishing to read or write a file issues a
`request to an operating system API for such action.
`2. The operating system checks if the request can be
`serviced from its file cache, if such cache is maintained.
`3. On a miss, or write through,
`the operating system
`directs the request to an appropriate device driver for
`the physical device to which the request was made.
`4. Optionally, the device driver may issue the request to
`the computer’s BIOS.
`5. The device driver (or BIOS) issues the request to a disk
`adapter, whichis a componenttypically installed on the
`motherboard of the PC.
`
`6. The disk adapter uses a physical connection to send the
`request to the controller of the local hard disk.
`It is an object of the present invention to implement the
`LDIMto intercept the request from the disk adapter so that
`the controller of the local persistent storage device will not
`receive it. Alternatively, it is an object of the invention to
`implement
`the LDIM to intercept
`the request from the
`device driver (or BIOS) so that the disk adapter does not
`receiveit.
`
`There are a number of ways in whichthis interception can
`be done including system management mode, a PC card,
`building it with new chips on the motherboard or the
`persistent storage device, or building the functionality into
`the adapter chip. The Alternative Embodiments section of
`this document elaborates on these embodiments.
`It is another object of the present invention to allow the
`DIMSto encrypt writes and decrypt reads using a password,
`a pass-phrase, or a key supplied by system software or the
`user. As commonly done,
`the key itself could be kept
`encrypted and only be decrypted after a password or a
`pass-phrase are supplied. The obvious advantage of encryp-
`tion is to secure the local data, the remote data, and the data
`transferred over the network. Furthermore, this functionality
`is transparentto the uscr, the operating system, and software
`applications.
`It
`is another object of the present invention to allow the
`DIMSto work with any operating system presentlyavailable
`on the market (including DOS, Windows 98/NT/2000/ME,
`Unix, Novell, OS/2, BeOS) or any future operating system
`that supports any of the standard persistent storage device
`interfaces.
`
`is another object of the present invention to allow the
`It
`DIMSto work with any standard hard drive interface.
`It
`is another object of the present invention to make the
`above functionalities available for any existing or future
`computer hardware that uses any of the current or future
`persistent storage device interfaces.
`It
`is another object of the present invention to provide a
`transparent mechanism for upgrading software and hard-
`ware drivers by meansof pulling changes as needed when
`the computer is connected to the network. This is as opposed
`to current operating system specific push mechanisms, such
`as Unix’s rdist.
`
`
`
`

`

`US 6,477,624 Bl
`
`7
`It is another object of the present invention to provide a
`mechanism for allowing users to roam from computer to
`computer and receive their personal operating system, per-
`sonalization customizations, applications, and data files, no
`matter what operating system, applications, and data files
`were previously being used on that computer.
`It is another object of the present invention to provide a
`mechanism allowing the DIMSto transparently present a
`large amountof storage space (bound only by the addressing
`size limitations), regardless of the amount ofspace available
`on the local physical persistent storage device.
`Still other objects and advantages of the invention will in
`part be obvious and will
`in part be apparent from the
`specification.
`Further features and advantages of the present invention,
`as well as the structure and operation of various embodi-
`ments of the present invention, are described in detail below
`with reference to the accompanying drawings.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The accompanying drawings, which are incorporated
`herein and form part of the specification, illustrate various
`embodiments of the present invention and, together with the
`description, further serve to explain the principles of the
`invention and to enable a person skilled in the pertinent art
`to make and use the invention. In the drawings,like refer-
`ence numbers indicate identical or functionally similarele-
`ments. Additionally,
`the left-most digit(s) of a reference
`numberidentifies the drawing in which the reference num-
`ber first appears.
`FIG. 1 depicts a functional block diagram of a standard
`PC indicating the connection and interaction of a typical
`persistent storage device;
`FIG. 2 depicts a computer and a data image management
`system (DIMS), according to one embodiment, for improv-
`ing the operation of the computer.
`FIG. 3 depicts a schematic of a PC with an installed local
`data image manager (LDIM).
`FIG. 4 depicts a block diagram of the components of an
`exemplary LDIM in accordance with the present invention;
`FIG. 5 depicts a flowchart of the LDIM control program;
`FIG. 6 depicts a flowchart of the PI (PIO In) commands
`executed by a computer;
`FIG. 7 depicts a flowchart of the PO (PIO Out) commands
`executed by a computer; and
`FIG. 8 depicts a flowchart of the ND (Non Data) com-
`mands executed by a computer.
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`The following detailed description of an embodiment of
`the invention is of the best presently contemplated mode of
`carrying out the invention. This description is not to be taken
`in a limiting sense, but is made merely for illustrating the
`general principles of the invention.
`FIG. 1 depicts a functional block diagram of a conven-
`tional computer 100 (also referred to as “PC”). As shown,
`computer 100 includes an operating system (OS) 102, a
`basic input/out system (BIOS) 104; a loadcr 106, a varicty
`of software programs 108 and a local persistent storage
`device (e.g., hard disk) 110 As the figure exemplifies,
`opcrating system 102, BIOS 104, and loader 106 (through
`the BIOS) access storage device 110 through a standard
`interface/protocol 112 (e.g.,
`the ATAAIDE interface/
`protocol). Conventionally, applications programs 108 do not
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`accessstorage device 100 directly; application programs 108
`rely on services provided by operating system 102 to access
`data stored on storage device 110.
`FIG. 2 depicts computer 100 and a data image manage-
`ment system (DIMS), according to one embodiment, for
`improving the operation of computer 100. The DIMSis 110
`a client/server system, and thus includesa client 202 and a
`server 204. Client 202 is referred to as the “local data image
`manager” (LDIM)and server 204 is referred to as the
`“remote data image manager” (RDIM). The DIMS also
`includes a persistent storage device (PSD) 206 that can be
`read from and written to by RDIM 204. PSD 206 is referred
`to herein as “remote PSD 206” or “RPSD 206”becauseit is
`
`“remotely” located from computer 100. That is, RPSD 206
`is not directly coupled to computer 100.
`As shown in FIG. 2, LDIM 202 is installed in computer
`100. More specifically, from a functional point of view,
`LDIM 202is installed between storage device 110 and OS
`102, and BIOS 104. LDIM 202, as shown in FIG. 2,
`communicates with OS 102 and BIOS 104 using standard
`interface 112; the same interface used by OS 102 and BIOS
`104 to communicate with storage device 106. Additionally,
`LDIM 202 may be connected to storage device 110 and can
`read data from and write data to storage device 110 using
`standard interface 112. 'lo OS 102 and BIOS 104, LDIM 202
`“pretends”that it is storage device 110. Thus, LDIM 202 is
`completely transparent to OS 102 and BIOS 104.
`LDIM 202 and RDIM 204 communicate with each other
`through a direct communication link or network 210 (e.g., a
`local area network, a wide are network, the Internet, the
`public switched telephone network, a wireless network,
`etc.).
`As described in the Summaryof Invention section, the
`DIMSallows for the storing of a data image on RPSD 206
`with storage device 100 serving as a persistent, consistent
`cache of the data image. A data image stored on RPSD 206
`is referred to as a “master data image” and a data image
`stored on storage device 110 is referred to as a “cached data
`image.” RPSD 206 can be configured to store more than one
`master data image and storage device 110 can be used to
`cache more than one master data image.
`Optionally,
`in one embodiment, LDIM 202 includes a
`“mini-booter” software program (not shown).
`In this
`embodiment, when computer 100 is powered on, LDIM 202
`“forces” the “mini-booter” into computer 100’s CPU (See
`FIG. 3). This is done by emulating a disk with the mini-
`booter installed as a loader. The mini-booter functions to
`authenticate the user (ic.,
`it may perform username/
`passwordverification). Additionally, if the DIMS has more
`than one RPSD 206, the user is prompted to select one.
`Preferably, the user will select the RPSD 206that stores the
`master data image(s) that “belong(s)” to the user. After the
`mini-booter receives the selection from the user, the mini-
`booter communicates with LDIM 202 (this communication
`can use custom IDE commands, or reads and writes to
`reserved sectors) to request
`that LDIM 202 contact
`the
`RDIM 204 associated with the selected RPSD 206 to
`
`determine the list of available master data images for this
`user.