Digital content security system6973576Abstract A Personal Digital Key Digital Content Security System (PDK-DCSS) is used to protect computers from unauthorized use and protect the digital content stored on computers from being wrongfully accessed, copied, and/or distributed. The basic components of the PDK-DCSS are (1) a standard hard drive device, with the addition of a PDK Receiver/Decoder Circuit (PDK-RDC) optionally integrated into the hard drive's controller, and (2) a PDK-Key associated with the PDK-RDC. The PDK-Key and RDC technology is utilized to provide two categories of protection: (1) hard drive access control for providing Drive-Level and Sector-Level protection and (2) operating system-level independent file protection for providing File-Level and Network-Level protection. Claims 1. A method of securing digital content on a hard drive of computer, comprising: Description FIELD OF THE INVENTION
Referring to FIG. 7 generally, the present invention can be extended to store-bought content. To fully integrate store-bought content into the present invention, traditional store-bought content is modified in two ways. First, the content is distributed in a copy protected format (e.g., using any valid copy protection technology). Second, the content contains a unique content serial code. The content serial code may be contained either directly in the digital content or as a physical label. Each content serial code is designated by a content distributor during manufacturing and stored in the key provider's database. This database is later used to validate that each content serial code is unique and used only a prescribed number of times. To a consumer, a content serial code on their newly purchased store-bought content represents a download of a key-secured version of that content for free or a prescribed price. This key-secured copy provides the consumer with exactly the same advantages and freedoms as any other key-secured content. From the consumer's standpoint, the download process occurs exactly as any other standard key-secured content download with the exception of how the payment is handled. The "payment" is the content serial code. By providing all of the advantages of the present invention to consumers of legacy-capable store-bought content (by way of "content serial code downloads"), the scheme provides the industry with the first complete DRM solution. Referring to the specifics of FIG. 7, the process of implementing the core acquisition option of store-bought digital content 122 (see FIG. 5) proceeds as follows. At step 160, a receiver/decoder circuit 170 retrieves an account number from a consumer's physical key (transponder) 172 over a secure RF link, and the consumer's personal computer 174 reads a content serial code from the store-bought content 122. The store-bought content 122 contains the content serial code that uniquely identifies the content. The format of the content serial code may, for example, be PPPP.FFF.0123456789 where PPPP is a provider identification, FFF is a facility identification, and the numbers represent a sequence number. The store-bought content 122 incorporates a copy protection scheme such as Macrovision™, key2audio™, or SafeAudio™. Disc "copy flags" (specified in SDMI standards) may also be set to further inhibit duplication efforts. At step 161, the consumer enters such data as a password and purchase selection via the consumer's personal computer 174. The previously-read content serial code specifies that the method of payment is to a "content serial code—credit" (i.e., there is typically no charge for this download because the content serial code confirms that the download in process is of content that the consumer has already legitimately purchased). The data is transmitted to a content distributor's web site 176 from the consumer's personal computer 174. At step 162, the distributor's web site 176 transmits the content serial code, account number, and password to a key provider's web site 178. At step 163, the key provider's web site 178 authenticates all data against its databases 180 and 182 and, if authentic, returns such information as the account number, user label, number of users, software encryption key, and paid-flag (indicating the content serial code has been validated) to the distributor's web site 176. The key provider's web site 178 now sets the paid-flag to disable any further downloads and records the account number field in the content serial code database 182 for auditing purposes. If the data is not valid, the key provider's web site 178 sends a message to the distributor's web site 176 indicating the same. A counter, used for the key provider's billing purposes, is incremented. Each entry in the content serial code database 182 may include the following data fields: CDC#, paid-flag, and account number. At step 164, the distributor's web site 176 pulls the content file from its database 184, encrypts it with the software encryption key it received in step 163, and builds a final key-secured file that is then transmitted to the consumer's personal computer 174. No charge is typically assessed because a valid content serial code serves as "payment" for the download. At step 165, invoices 186 are generated and sent to content distributors by the key provider's web site 178 on a regular cycle. Referring to FIG. 8 generally, the present invention can be extended to broadcast content. To fully integrate broadcast content into the present invention, traditional broadcast content is only minimally modified. The modification is that the broadcast content is transmitted in a copy protected format (such as the DVD standard known as Content Scramble System (CSS)). The remainder of the process is described below. A key-enabled recording device, incorporating a unique identifier, receives copy-protected broadcast content. If only playback of the broadcast content is desired, basic decoding (e.g., CSS) is performed and the broadcast content is sent on for playback. If the consumer wishes to record the broadcast content, however, the recording device performs additional steps prior to sending the broadcast content on for playback. The recording device connects to the key provider's web site to validate the recording device's internal identifier and the consumer's physical key. If both are valid, the recording device translates the broadcast content into a key-secured format by encoding it with the consumer's activation code, and then stores the key-secured content file, with its identifier permanently embedded within, for later use. The end result is key-secured broadcast content that provides the owner of the associated physical key all the freedoms and advantages of the present invention. Although the content was originally broadcast, it cannot be illegally copied or distributed. The present invention can be applied to pay per view offerings, as well as standard broadcast material. Referring to the specifics of FIG. 8, the process of implementing the core acquisition option of broadcast digital content 124 (see FIG. 5) proceeds as follows. At step 180, a receiver/translator/recording device 190 receives digitally broadcast content in copy-protected format from a source 192 such as satellite, cable, Internet, or over-air. The broadcast content may be copy-protected using a copy-protection technology such as an enhanced CSS scheme. If a consumer wishes to only play (not record) the broadcast content, basic decoding (e.g., CSS decoding) is performed and the broadcast content is passed through to presentation device 194 for playback. The remaining steps below may be skipped. If, however, the consumer wishes to record the broadcast content, the following additional steps are performed prior to sending the broadcast content on for playback. At step 181, the receiver/translator/recording device 190 retrieves an account number from the consumer's physical key (transponder) 196 over a secure RF link. At step 182, the receiver/translator/recording device 190 transmits the account number and its recorder serial code to a key provider's web site 198. Each device 190 contains a recorder serial code that uniquely identifies the device. The format of the recorder serial code may, for example, be MMMM.FFF.0123456789 where MMMM is a manufacturer identification, FFF is a facility identification, and the numbers represent a sequence number. At step 183, the key provider's web site 198 authenticates the data against its databases 200 and 202 and returns an "approved" or "rejected" response. A counter, used for the key provider's billing purposes, is incremented. At step 184, if a "rejected" response is received, the broadcast content cannot be recorded. If an "approved" response is received, the receiver/translator/recording device 190 translates the decoded content into a key-secured format by encoding it with the consumer's activation code, and records the key-secured content, with the recorder serial code permanently embedded within, to a storage device (that can optionally be an external device). The broadcast content can now be copied to and played back on any key-enabled playback device. At step 185, invoices 199 are generated and sent to content distributors by the key provider's web site 198 on a regular cycle. While providing excellent additional security and protections, steps 182 and 183 are not mandatory for the present invention to function with broadcast content. It may be desirable, for cost purposes, to produce receiver/translator/recording devices 190 not capable of communicating with the key provider's web site 198. Referring to FIGS. 9a and 9b generally, having acquired key-secured digital content and produced copies for playback on various devices such as a portable CD player, personal computer, home theater, etc., a consumer is now ready to use the digital content. Playback of key-secured content occurs as follows. A key-enabled playback device transparently reads information from a consumer's physical key and from the content file the consumer has requested to play. The pieces of information are then compared to validate that the physical key "matches" the content to be played. If the elements match, the device begins playback of the content. If the elements do not match, the device will not play the content and, depending upon the device's capabilities, may display an "invalid content" message. From a consumer's point of view, when used with legitimately-acquired content, the process is entirely transparent, effortless, and non-intrusive. The consumer is free to use their content on any key-enabled playback device, with the only restriction being that the content can be played only when the associated physical key is present. As noted above, the present invention gives consumers unprecedented freedoms and conveniences to use legitimately purchased content while still fully protecting content providers' rights. Referring to the specifics of FIGS. 9a and 9b, the process of implementing the core playback option of stand-alone devices 126 (see FIG. 5) proceeds as follows. At step 210, a consumer requests playback of a key-secured content file via a playback device 220. The playback device 220 may, for example, be the consumer's personal computer (FIG. 9a) or a stereo amplifier (FIG. 9b) with integrated compact disc reader/player. At step 211, a receiver/decoder circuit 222 searches for a physical key (transponder) 224. The circuit 222 may be a separate component from the playback device 220 as in FIG. 9a or integrated into the playback device 220 as in FIG. 9b. If the physical key is not found, the playback device 220 displays an "invalid content" message. If the physical key is found, the receiver/decoder circuit 222 retrieves all available information from the physical key 224 over a secure RF link. At step 212, the user labels in the physical key 224 and the key-secured content file are compared. If the user labels do not match, the playback device 220 displays an "invalid" message. If the user labels do match, the receiver/decoder circuit 222 retrieves the software decryption key from the physical key 224 over the secure RF link between the physical key 224 and the playback device 220 and begins decryption of the encrypted portion of key-secured file. When the account number is decrypted, it is matched against the account number retrieved from the physical key 224. If the account numbers do not match, the playback device 220 displays an "invalid content" message. If the account numbers do match, the software decryption key is used by the playback device 220 to decrypt remaining data in the key-secured file for playback. The user label and the account number in the physical key serve as a first activation code, and the user label and the account number in the content file serve as a second activation code. These activation codes must match (or have some other predetermined association) in order for playback to proceed. Referring to FIG. 10 generally, while stand-alone playback devices (e.g., CD players, PCs, DVD players, etc.) are currently the norm, the convergence of these devices and the Internet will lead to an environment where centralized digital distribution systems proliferate. Security of content in these environments is critical yet challenging to accomplish without imposing great restrictions. The present invention can provide security to a centralized digital distribution system and, in addition, offers many important enhancements that greatly increase the convenience and usability of such a system. These enhancements include integration of the physical key into a portable handheld computer which then doubles as the system remote. In addition to controlling all networked components, the remote is used for tasks such as purchasing content from the Internet, and tracking the movement of a user throughout a facility to provide automatic "content following" (i.e., where content playback follows the user from room to room). The centralized nature of the digital content distribution system means that only one storage device is required to maintain a consumer's entire digital content library (e.g., music, movies, software, E-books, etc.) and to feed that content to any networked playback device. Referring to the specifics of FIG. 10, there is shown a centralized digital content distribution system for implementing the core playback option of networked devices 128 (see FIG. 5). The system is used in an establishment such as a residence or entertainment facility. The system includes a digital content server 310, a distribution hub 312, a plurality of remote clients 314, and a portable remote control 316. The digital content server 310 stores digital content acquired from a source 318 such as satellite, cable, Internet, or over-air. In addition, the digital content server 310 may store digital content uploaded from a standard component 324. The plurality of remote clients 314 are located in different rooms of the establishment and linked to the digital content server 310 via the distribution hub 312 or switch. The remote clients 314 are linked to the distribution hub 312 by a backbone transmission network 315. The backbone transmission network 315 may be wireless or wired with fiber optic cables, coaxial cables, or twisted pair cables, may employ a networking protocol such as Ethernet, Wi-Fi, Arcnet, or ATM (Asynchronous Transfer Mode), and may employ a communications protocol such as TCP/IP. Each remote client 314 includes a network interface card (NIC) for interfacing with the backbone transmission network 315. The remote control 316 is adapted to communicate with each of the remote clients 314 and select the digital content stored in the digital content server 310. The remote control 316 is essentially a personal digital assistant (i.e., hand-held computer) including a display and added remote control circuitry. The display may, for example, be a liquid crystal display (LCD). The added remote control circuitry includes "system remote" circuitry and "universal remote" circuitry. The "system remote" circuitry in the remote control 316 is for establishing a first wireless transmission link 320 with each of the remote clients 314. The first wireless transmission link 320 may be a secure radio link (RF) as shown or an infrared link (IR). Upon establishing the first wireless transmission link 320 with one of the remote clients 314, the remote control 316 serves as a system remote capable of (1) displaying, scanning, and selecting the digital content available on the digital content server 310 and downloading the selected digital content from the digital content server 310 to the linked remote client 314 and (2) controlling the digital content server 310 to acquire or download digital content from a source 318 such as satellite, cable, Internet, or over-air. As used herein, the term "download" and similar variations thereof (e.g., downloaded, downloading, etc.) is intended to cover the transfer of content from one device to a receiving device whether the content is stored on the receiving device or merely "streamed" to the receiving device for immediate playback. The remote control 316 preferably includes a display for displaying the digital content. The display may, for example, be a liquid crystal display (LCD). As a user holding the remote control 316 moves from room to room of the establishment, the remote control 316 successively establishes wireless transmission links 320 with the remote clients 314 in the respective rooms. In this way, the digital content available on the digital content server 310 follows the user's movement from room to room. In a preferred embodiment, the first wireless transmission link 320 is a secure radio link established by matching transceivers in the remote control 316 and each remote client 314. The matching transceivers are preferably small, inexpensive Bluetooth™ radio chips that operate in the unlicensed ISM band at 2.4 GHz and avoid interference from other signals by hopping to a new frequency after transmitting or receiving a packet. The radio chips are integrated into the respective remote control 316 and each remote client 314, which can then communicate over short distances and through obstacles by means of radio waves. Wireless technologies other than Bluetooth, such as Wi-Fi, may be used to communicate remote control signals between the remote control 316 and each remote client 314. The "universal remote" circuitry in the remote control 316 is for establishing a second wireless transmission link 322 with standard components 324 connected to the remote clients 314. The second wireless transmission link 322 is preferably an infrared link (IR) as shown. Upon establishing the second wireless transmission link 322 with one of the standard components 324, the remote control 316 serves as a universal remote capable of operating the standard component 324. The standard component 324 may, for example, be an audio receiver (stereo amplifier), an audiovisual receiver, a video monitor (television), etc. The standard components 324 may be physically separate from, but linked to, the respective remote clients 314 or may be physically integrated into the respective remote clients 314 like integrated device 324c. The digital content stored on the digital content server 310 may be formatted as a compact disc (CD), digital video disc (DVD), MP3, electronic book, software, etc. When the remote control 316 is linked to one of the remote clients 314, a user may scan and select digital content to be downloaded from the digital content server 310 to the remote client 314 and converted by the remote client 314 to a standard playable format (e.g., analog format) that can be played on the associated standard component 324. The selected digital content is downloaded from the digital content server 310 to the remote client 314 as raw digital data packets. The remote client 314, in turn, converts the downloaded digital content to a standard component output(s) compatible with a standard component 324 connected to the remote client 314, and the standard component 324 plays the digital content. Ports may, for example, include S-Video, RCA jacks, serial ports, Universal Serial Bus, Ethernet, Wi-Fi, Firewire™, Bluetooth, RF, or other similar outputs. The standard component 324 incorporates, or is linked to, audio speakers for broadcasting any audio signals received from the remote client 314 and a video monitor for displaying any video signals received from the remote client 314. All content is stored on the digital content server 310 digitally, and is key-secured if obtained via the download or broadcast acquisition options of FIGS. 6 and 8. If the digital content is key-secured, the plurality of remote clients 314 include decryption circuitry (i.e., receiver/decoder circuit) for unlocking the digital content. The digital content selected for download from the digital content server 310 to a remote client 314 preferably remains encrypted until converted to a standard component output(s) in the remote client 314. The remote client 314 acts as a converter between key-secured digital content from the digital content server 310 and the standard component output(s). To decrypt the selected digital content, the remote control 316 contains a physical key initially acquired from a key provider in accordance with the present invention. The digital content is initially acquired from a content provider 326 that marks the digital content with an activation code associated with the physical key. The decryption circuitry in the remote client 314 receives an activation code from the remote control 316 via the wireless transmission link 320 and is enabled to unlock and convert the digital content to a playable format if the activation code in the remote control 316 is associated with the activation code in the digital content. If the activation code in the remote control 316 is not associated with the activation code in the digital content, the remote client 314 will not unlock and convert the digital content. In an alternative embodiment, the remote clients 314 are eliminated and the standard components 324 are linked directly to standard component outputs of the distribution hub 312 by the backbone transmission network 315. In this case, the distribution hub 312 serves as a switch, and the digital content server 310 contains the decryption circuitry for unlocking the digital content. As the digital content is decrypted, it is converted to a playable format and fed to the distribution switch 312 for delivery to the appropriate standard component 324. The decryption circuitry in the digital content server 310 receives the activation code from the remote control 316 and is only enabled to unlock and convert the digital content to a playable format if the activation code in the remote control 316 is associated with the activation code in the digital content. Instead of decrypting the digital content so that it can be played, the digital content may be downloaded (or "passed through") in its encrypted format to a storage device such as a media burner 324a or computer hard disk 324b for storage thereon. When a user ultimately desires to play the stored digital content on a media player, the media player must contain the decryption circuitry for unlocking the digital content. After unlocking the digital content, the media player converts the unlocked digital content to a playable format and plays the digital content. The decryption circuitry in the media player receives the activation code from the remote control 316 or physical key with the same activation code. The media player is only enabled to unlock and convert the digital content to a playable format if the activation code in the remote control 316 or physical key is associated with the activation code in the digital content. In addition to downloading selected digital content from the digital content server 310 to the remote clients 314, data (e.g., MP3, CD, DVD, software, etc.) from the standard components 324 can be uploaded to the digital content server 310 and stored digitally thereon. This allows for storage of legacy content on the digital content server 310. Referring to FIG. 11 generally, a digital content security system and method protects computers from unauthorized use and protects the digital content stored on computers from being wrongfully accessed, copying, and/or distributed. The basic components of the Personal Digital Key Digital Content Security System (PDK-DCSS) are (1) a standard hard drive device 330, with the addition of a PDK Receiver/Decoder Circuit (PDK-RDC) 332 integrated into the controller 334, and (2) a PDK-Key 336 associated with the PDK-RDC as described above. The standard computer hard drive 330 incorporates the integrated PDK-RDC 332 for the purpose of enabling multiple methods of securing digital content. Hard drives 330 incorporating a PDK-RDC 332 are referred to herein as PDK hard drives. While the PDK-DCSS diagrams show the PDKRDC 332 as being integrated with the hard drive's controller 334, all OS-level protections described below can be implemented using externally-based PDK-RDCs. A PDK hard drive 330 is similar to any standard, currently available hard drive with the exception of the PDK-RDC 332 (which is integrated into the drive's controller circuit 334). A PDK-RDC 332 is an integrated circuit able to process PDK-Key information, as well as encrypt/decrypt PDK-compliant digital content. Additionally, this circuit 332 is able to secure the hard drive 330 itself. This is implemented by the circuit 332 enabling or disabling the hard drive's controller 334 depending on whether an associated PDK-Key 336 (one which is uniquely and permanently associated with the PDK hard drive 330) is present. Each PDK hard drive 330 would typically be delivered with its own PDK-Key 336. Secure RF communications between a PDK-Key 336 and its associated hard drive 330 occurs in the same manner as described above. It should be noted that software drivers can optionally be designed to allow for dynamic key assignment (assigning of keys after purchase to enable key swapping, or assigning of individual keys to multiple devices). The PDK-Key and RDC technology is utilized to provide two categories of protection:
By utilizing these two categories of protection in various ways, four unique levels of content protection are enabled. Two of the levels (Drive-Level and Sector-Level) do not require external software support, while the remaining two (File-Level and NetworkLevel) require software drivers, as well as a stand-alone application for Network-Level implementations. Each of the four levels is defined below. Referring to FIGS. 12 and 13 for Drive-Level protection, when implemented, a PDK hard drive 330 will only function when the associated PDK-Key 336 is within range. The drive's controller 334 is disabled whenever the PDK-Key 336 is not present. The contents of files stored on the drive 330 are not encrypted. The Drive-Level protection feature is designed to protect the hard drive's owner by locking access to the PDK hard drive 330 whenever the associated PDK-Key 336 is not present (i.e. when the owner momentarily steps away from the computer, if the computer is stolen, etc.). Referring to FIGS. 12 and 13 for Sector-Level protection, when enabled, every sector (or cluster of sectors) read or written is encrypted/decrypted by the RDC 332 using the drive's associated PDK-Key 336. Because the encryption is performed at Sector-Level as opposed to File-Level, the encoding can be accomplished without requiring any changes, involvement, or acknowledgement of the OS responsible for managing the drive. The Sector-Level protection feature is designed to further protect the hard drive's owner (beyond Drive-Level protection) by encrypting the contents of the files stored on the drive, without requiring any software modifications (OS, application, etc.). The security advantage is that if the drive access is in some way defeated, the contents of files on the drive are still protected. It should be noted that if users retrieve files from drive and purposely transfer them anywhere else (via email, memory sticks, etc.), the data will no longer be protected. Drive-Level protection and Sector-Level protection may be used individually or in combination. Also, as noted above, it should be understood that Sector-Level protection may be applied to individual data sectors or clusters of data sectors. FIG. 13 illustrates the logic executed by the RDC 332 for implementing Drive-Level protection and Sector-Level protection. The logic ensures OS-level commands (save entire file, read entire file, etc.) are given adequate time to complete. This enables implementation of logic without requiring OS changes, involvement, or acknowledgement. Referring to FIG. 14 for File-Level protection, implemented as an OS-level software driver utilizing the PDK-RDC 332 integrated in the PDK hard drive 330, File-Level protection provides standard PDK digital rights management services and functionality as described above. As needed, the driver instructs the RDC 332 to acquire PDK-Key information, validate the key-to-file match, and use the key's information to perform actual encryption/decryption of the file (as a whole, not at the sector level). In the illustrated example, the file ABC 338 (which can reside on any storage device, in memory, etc.) is compared to any PDK-Key 336 within range of the PDK-RDC 332. If a match is found, the PDK-RDC 332 will decrypt the file 338 for use with whatever playback mechanism placed the request. Any PDK-Key 336 can be utilized, not just the key 336 associated with the PDK hard drive 330. When employed for File-Level protection (and Network-Level protection as described below), the PDK-RDC 332 functions independently of the hard drive 330 in which it resides. While PDK-compliant files it encrypts or decrypts may reside on the resident hard drive 330 and may be associated with the drive's PDK-Key 336, they do not have to be. The PDK-RDC 332 can work with other PDK-Keys and files residing on other mediums. When used in this manner, the PDK-RDC 332 can be thought of as just coincidently residing within the hard drive 330. For File-Level and Network-Level protection, the RDC 332 may be implemented as a separate circuit board (not integrated within the hard drive 330) and still provide identical functionality. The primary use of File-Level protection is to secure and protect private or copyrighted material from wrongful copying and distribution. Because copies of any PDK-compliant files can only be accessed when the associated PDK-Key is present, File-Level protection enables copies (intended for use by the holder of the associated key) to be produced effortlessly and securely. In addition to the distribution of copyrighted content such as music and movies as described above, software developers can distribute their software products via the Internet with the same ease and security. Software distributed in this manner would allow the legal recipient to make unlimited copies (for backup purposes, use on a home computer, etc.), yet the copies would only function when the associated key is present, preventing unauthorized copies from being wrongfully distributed and used. The File-Level protection feature is designed to protect publishers of private or copyrighted material. Users can protect any file by converting it to PDK-compliant format; however, security of document files can be compromised by key holders not wishing to maintain the file's integrity. Because, while a Microsoft Word document (as an example) may be stored in the PDK-compliant protected format, once opened the contents could be cut and pasted into another application (e.g., an email program) thereby defeating the protection. Therefore the use of File-Level protection for use with documents is only applicable for entrusted recipients (individuals desiring to protect the content of which they are in possession). Non-document files, however, are not subject to these limitations. Referring to FIG. 15 for Network-Level protection, File-Level Protection can be expanded to a network environment by employing a centralized software application/database called a PDK Document Controller (DC) 340 running on a server 342. A DC 340 enables the creation of Groups 342 that list which PDK-Keys 344 are allowed access to files in specific directories. All files stored in directories controlled by the DC 340 are automatically encrypted using the DC administrator's PDK-Key and thereby become PDK-compliant files. This process places all files stored in the DC 340 in a uniformly encrypted format. Each user request for a file residing in a directory listed in a DC Group 342 results in the following steps. An RDC located in the requester's workstation 346 acquires information from the user's PDK-Key 344 and relays that information to the DC 340. The DC then enables appropriate access as defined by the DC's Group database information. Specifically, the DC 340 performing a lookup of the requester's PDK-Key 344 in the appropriate Group's tables. If the DC 340 determines that the PDK-Key 344 is listed in a Group 342 that also lists the directory containing the file the user wishes to access, the DC 340 knows that a valid PDK-Key 344 was used in the file request and grants access. The requested file is first decrypted with the administrator's PDK-Key, re-encrypted with the requester's PDK-Key 344, and then downloaded to the user's workstation 346. The foregoing process mirrors the process employed when using PDK to download digital media files from the Internet. The Network-Level protection feature is designed to protect publishers of private or copyrighted material. Users can protect any file by converting it to PDK-compliant format; however, security of document files can be compromised by key holders not wishing to maintain the file's integrity. Because, while a Microsoft Word document (as an example) may be stored in the PDK-compliant protected format, once opened the contents could be cut and paste into another application (e.g., an email program) thereby defeating the protection. Therefore, the use of File-Level protection for use with documents is only applicable for entrusted recipients (individuals desiring to protect the content of which they are in possession). Non-document files, however, are not subject to these limitations. The system is well suited for establishing centralized databases of secure documents intended for distribution to entrusted recipients such as personnel in a law firm or medical facility. While the present invention has been described with reference to one or more particular embodiments, those skilled in the art will recognize that many changes may be made thereto without departing from the spirit and scope of the present invention. Each of these embodiments and obvious variations thereof is contemplated as falling within the spirit and scope of the claimed invention, which is set forth in the following claims.
|
Same subclass Same class Consider this |
||||||||||
