Patent Application
20070070832
Computers often read and/or write data to removable media. Examples of removable media include, without limitation, magnetic media such as a floppy disk, tape, or removable hard disk drive and optical media such as a compact disk (CD) or digital video disk (DVD). An item of removable media is typically inserted into a “drive” that is communicatively coupled to a computer. The computer communicates with the drive in order to write data to and/or read data from the item of removable media inserted into the drive.
Typically, a user of a computer is able to cause an item of removable media to be ejected from a drive in at least two ways. In one way, a user interacts with software executing on the computer (for example, via a graphical user interface provided by an operating system executing on the computer) in order to request that the inserted item be ejected from the drive. This interaction is also referred to here as an “eject request.” The computer determines if it is appropriate for the item of removable media to be ejected from the drive at that time. If it is appropriate to eject the inserted item at that time, the computer sends a command (also referred to here as an “eject command”) to the drive, which causes the drive to eject the inserted item. In one example, when the computer receives an eject request while the computer is performing an input/output operation on the inserted item, the computer waits for the input/output operation to complete before sending an eject command to the drive in order to eject the item of removable media. Such an eject operation is also referred to here as a “software” eject or a “soft eject.”
Another way in which a user of a computer is able to cause an item of removable media to be ejected from a drive is by actuating an “eject button” located on the drive itself. In one embodiment, when a user actuates the eject button, the drive sends an eject request to the computer. The computer receives the eject request and determines if it is appropriate for the item of removable media to be ejected from the drive at that time. If it is appropriate to eject the inserted item at that time, the computer sends an eject command to the drive, which causes the drive to eject the inserted item. In another embodiment, the eject button comprises an “emergency-eject” button that, when actuated, causes the drive to eject any item of removable media inserted into the drive without “checking with” any computer to which the drive is communicatively coupled and without regard to the state of any such computer.
Typically, however, such drive units do not include any mechanism to reduce the likelihood that an inserted item of media will be forcibly removed from the drive. Also, typically, any emergency-eject button is located on the drive (for example, on the front surface of the drive) such that a user can actuate the emergency-eject button while the drive is communicatively coupled to the computer. Any computer to which such a drive is communicatively coupled typically has no way of preventing an item of removable media from be forcibly removed from drive or from being ejected from the drive using an emergency-eject button in situations when the computer would otherwise not permit the drive to eject the inserted item (for example, when an input/output operation is still being performed or when a security policy implemented on the computer does not allow a user to eject the inserted item).
Like reference numbers and designations in the various drawings indicate like elements.
The computer 100 further comprises memory 106 in which at least a portion of the software 104 (and related data structures) is stored during execution by the CPU 102. Memory 106 comprises any suitable memory now known or later developed such as, for example, random access memory (RAM), read only memory (ROM), and/or registers within the CPU 102.
In the embodiment shown in
The computer 100 further comprises a drive bay 116 into which a secure removable media drive 118 is inserted. In the embodiment shown in
The various components of the computer 100 are communicatively coupled to one another as needed using appropriate interfaces, for example, buses, ports, and the like.
The drive 118 also comprises one or more media interfaces 208 that physically read data from and/or write data to a respective item of media 201 inserted into the drive 118. In the particular embodiment shown in
The drive 118 further comprises a computer interface 212 to communicatively couple the drive 118 to the computer 100 (and the other components thereof) when the drive 118 is inserted into the drive bay 116 of the computer 100. The computer interface 212 comprises an interface that is compatible with (and mates with) the drive interface 120 included in the computer 100 to which the drive 118 is coupled. For example, in one implementation where the drive 118 supports optical disks, the computer interface 212 comprises an ATAPI or SCSI interface for communicatively coupling the optical drive to a computer (and the other components thereof). In other implementations and embodiments, other types of computer interfaces 212 (for example, an IDE, USB, or FIREWIRE interface) are used.
The drive 118 further comprises a media ejector 214 that is mechanically coupled to the media support 202 for ejecting from the drive 118 each item of removable media 201 that is inserted into the drive 118. In the particular embodiment shown in
The drive 118 further comprises a lock 216 (also referred to here as a “hardware” lock or “physical” lock 216). The lock 216 is used to physically lock an inserted item of removable media 201 in the drive 118. That is, the lock 216 prevents such inserted item of removable media 201 from being ejected (or otherwise removed) from the drive 118 when the lock 216 is in a locked state. When the lock 216 is in an unlocked state, an item of removable media 201 that is inserted into the drive 118 is able to be ejected from the drive 118. In the particular embodiment shown in
The drive 118 further comprises a drive access controller 224. The drive access controller 224 is communicatively coupled to the computer interface 212 So that the drive access controller 224 is able to communicate with any computer 100 to which the drive 118 is communicatively coupled. The drive access controller 224 controls the lock 216 and the media ejector 214. In the embodiment shown in
The drive 118 further comprises a user-accessible eject switch 228. The user-accessible eject switch 228 is located in a location that is physically accessible by a user of the drive 118 when the drive 118 is communicatively coupled to the computer 100 (for example, when the drive 118 is inserted into the drive bay 116 of the computer 100). In the embodiment shown in
The drive 118 further comprises an emergency eject mechanism 230 for mechanically ejecting an inserted item 201 from the drive 118 regardless of whether the drive 118 is locked or unlocked. The emergency eject mechanism 230 comprises a user interface 232 (also referred to here as the “emergency eject user interface” 232) by which a user of the drive 118 is able access the emergency eject mechanism 230. The emergency eject user interface 232 is located in a location that is not accessible by a user of the drive 118 when the drive 118 is communicatively coupled to the computer 100 (for example, when the drive 118 is inserted into the drive bay 16 of the computer 100). In the embodiment shown in
In one implementation, the emergency eject user interface 232 comprises a hole 236 formed in the internal surface 234 where the emergency eject user interface 232 is located. A user of the drive 118 is able to insert a rod (or other rigid member) into the hole 236 when the drive 118 is removed from the drive bay 116 of the computer 100. In such an implementation, the emergency eject mechanism 232 further comprises a lever 238 that receives a rod inserted into the hole and directs the force applied to the rod to move the bolt 220 of the lock 216 into the unlocked position (if the lock 216 is locked) and to move the spring catch 217 of the media ejector 214 in order to release the spring 215 of the media ejector 214. Releasing the spring 215 causes the spring 215 to move the media support 202 and the inserted item of media 201 through the media slot 204. In other embodiments and implementations, the emergency eject mechanism 232 and emergency eject user interface 234 are implemented in other ways.
In other implementations and embodiments, the secure removable media drive 118 is implemented in other ways. In one such alternative embodiment, each item of removable media comprises a removable hard disk. The removable hard disk comprises multiple rotating platters of magnetic media, one or more motors to rotate the platters, and one or more media interfaces to read data from and/or write data to the platters. In such an embodiment, the drive 118 need not include a motor and a media interface since such functionality is included in each removable hard disk.
When the drive access controller 224 receives information from the computer 100 indicating that the drive 118 should be locked (checked in block 402), the drive access controller 224 “locks” the drive 118 (block 404). When the drive access controller 224 receives information from the computer 100 indicating that the drive 118 should be unlocked (checked in block 406), the drive access controller 224 “unlocks” the drive 118 (block 408). In one implementation of such an embodiment,.the driver 122 executing on the computer 100 to which the drive 118 is communicatively coupled sends a “lock command” to the drive 118 in order to lock the drive 118 and the driver 122 sends an “unlock command” to the drive 118 in order to unlock the drive 118. The driver 122 sends the lock commands and the unlock commands to the drive 118 via the drive interface 120, which the drive access controller 224 of the drive 118 receives via the computer interface 212. The drive access controller 224 locks the drive 118 by energizing the solenoid 218 of the lock 216 in order to move the bolt 220 into the locked position, which prevents the inserted item of removable media 201 from being ejected from the drive 118. The drive access controller 224 unlocks the drive 118 by energizing the solenoid 218 of the lock 216 in order to move the bolt 220 into the unlocked position so that the bolt 220 does not prevent the inserted item of removable media from being ejected from the drive 118. In other embodiments, the drive 118 is locked and unlocked in other ways.
In one such implementation, the operating system 108 supports multiple users, where only one user is able to log into the computer 100 locally at a time. In such an implementation, the operating system 108 supports a security policy in which only certain users have sufficient access rights to eject an item of removable media 201 inserted into the drive 118 by performing either a soft eject or a secure hard eject operation. Whenever a user having sufficient access rights to eject an item of removable media 201 from the drive 118 locally logs into the computer 100, the driver 122 sends an unlock command to the drive 118. Otherwise, whenever a user having insufficient access rights to eject an item of removable media 201 from the drive 118 locally logs onto the computer 100 or when no user is locally logged onto the computer 100, the driver 122 sends a lock command to the drive 118. Also, in such an implementation, the driver 122 sends a lock command to the drive 118 whenever a user having sufficient access rights locks that user's current session of the computer 100 (for example, when the user wishes to leave the computer 100 for an extended period of time but does not want to log out of the user's current session). When the user subsequently unlocks the user's current session (for example, by supplying a user password to the operating system 108), the driver 122 sends an unlock command to the drive 118.
When the drive access controller 224 determines that the user-accessible eject switch 228 has been actuated (block 410), if the drive 118 is unlocked (checked in block 412), the drive access controller 224 ejects the inserted item of removable media 201 from the drive 118 (block 414). If the drive 118 is locked, the item of removable media 201 is not ejected from the 118. The drive access controller 224, in the embodiment shown in
When the drive access controller 224 receives an eject command from the computer 100 via the computer interface 212 (checked in block 416), if the drive 118 is unlocked (checked in block 418), the drive access controller 224 ejects the inserted item of removable media from the drive 118 (block 420). If the drive 118 is locked, the item of removable media 201 is not ejected from the 118. For example, in one usage scenario, a user interacts with a graphical user interface provided by the software 104 executing on the computer 100 in order to request that a soft eject operation be performed. In such an example, the driver 122 determines if it is appropriate to eject the inserted item and, if it is appropriate, sends an eject command to the drive access controller 224 of the drive 118. If the drive 118 is unlocked when the eject command is received by the driver access controller 224, the driver access controller 224 ejects the inserted item of removable media 201. In other embodiments, an eject command is sent to the drive access controller 224 of the drive 118 in other situations. The drive access controller 224 ejects the item of removable media 201 by energizing the solenoid 218 in order to move the bolt 220 of the lock 216 into the unlocked position (if the lock 216 is locked) and applies a control voltage to the transducer 219, which causes the transducer 219 to release the spring catch 217. When the spring catch 217 is released, the spring 215 uncompresses and moves the media support 202 (and the inserted item of removable media 201 thereon) out of the drive 118 through the media slot 204. In other embodiments, the item of removable media 201 is ejected from the drive 118 in other ways.
If a user accesses the emergency eject mechanism 230 via the emergency eject user interface 232 (checked in block 422), the emergency eject mechanism 230 causes the item of removable media 201 to be ejected from the drive 118 regardless of the state of the drive 118 (block 424). In order for a user to access the emergency eject mechanism 230, the drive 118 is removed from the drive bay 116 in order to access the emergency eject user interface 232. For example, in one usage scenario that makes use of the drive 118 of
The drive 500 does not include a physical lock (such as physical lock 216 of
When the lock value is stored in the lock memory 502, the drive access controller 224 considers the drive 500 to be locked and when the unlock value is stored in the lock memory 502, the drive access controller 224 considers the drive 500 to be unlocked. While the drive 500 is locked (that is, while the lock value is stored in the lock memory 502), the drive access controller 224 does not eject an item of removable media 201 inserted into the drive 500 in response to the user-accessible eject switch 228 being actuated. While the drive 500 is unlocked (that is, while the unlock value is stored in the lock memory 502), the drive access controller 224 ejects an item of removable media 201 inserted into the drive 500 in response to the user-accessible eject switch 228 being actuated.
In some implementations of such an embodiment, each lock command and unlock command sent to the drive 500 comprises a key. When a lock command is received by the drive 500, the drive 500 stores the key in the lock memory 502 as a part of the lock value. When an unlock command is subsequently received by the drive 500, the key included in the unlock command is compared to the key stored in the lock memory 502 and if the keys match, the drive 500 unlocks the drive 500. In one such implementation, the keys are encrypted and/or authenticated using cryptographic technology (for example, using public key encryption technology).
In some other embodiments, a drive comprises both a lock memory (such as lock memory 502 of
The methods and techniques described here may be implemented in digital electronic circuitry, or with a programmable processor (for example, a special-purpose processor or a general-purpose processor such as a computer) firmware, software, or in combinations of them. Apparatus embodying these techniques may include appropriate input and output devices, a programmable processor, and a storage medium tangibly embodying program instructions for execution by the programmable processor. A process embodying these techniques may be performed by a programmable processor executing a program of instructions to perform desired functions by operating on input data and generating appropriate output. The techniques may advantageously be implemented in one or more programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory previously or now known or later developed, including by way of example semiconductor memory devices, such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and DVD disks. Any of the foregoing may be supplemented by, or incorporated in, specially-designed application-specific integrated circuits (ASICs).
