the preferred embodiment of the present invention and its advantages are best understood by referring to fig1 through 7 of the drawings , like numerals being used for like and corresponding parts of the various drawings . fig1 is a block diagram showing the components of a sample lcs system and showing the possible paths for content to enter and leave the lcs . in the embodiment of fig1 , the lcs is a general purpose computing device such as a pc with software loaded to emulate the functions of a lcs . the lcs of fig1 has a rewritable media ( such as a hard drive ), a read - only media ( such as a cd - rom drive ), and software to control access ( which software , in effect , defines the “ lcs domain ”). the secure electronic content distributor ( secd ) is connected via a network ( such as the internet , intranet , cable , satellite link , cellular communications network , or other commonly accepted network ). the satellite unite ( su ) is a portable player which connects to the lcs and / or to other players where applicable ( for example by way of a serial interface , usb , ieee 1394 , infrared , or other commonly used interface protocol ). fig1 also identifies seven ( 7 ) path ways . path 1 depicts a secure distribution of digital content from a secd to a lcs . the content can be secured during the transmission using one or more ‘ security protocols ’ ( e . g ., encryption or scrambling ). moreover , a single lcs may have the capability to receive content transmissions from multiple secds , and each secd may use the same security protocols or different security protocols . in the context of fig1 , however , only a single secd is displayed . it is also contemplated that the same secd may periodically or randomly use different security protocols . a typical security protocol uses an asymmetric cryptographic system , an example being a public key cryptography system where private and public key pairs allow the lcs to authenticate and accept the received content . another security protocol may involve the ability to authenticate the received content using a signature scheme . in fig2 , content enters the lcs domain from the rewritable media ( such as a hard drive ). this communication path is identified as path 2 on fig1 . the lcs domain analyzes the content to determine if a watermark is present in the content . if no watermark is present , then the quality of the content is downgraded to low quality before it is stored in the lcs storage . if a watermark is present , then the watermark is extracted and compared with the watermark of the lcs in order to determine if a match exists . in the event of a match , the content is permitted to be stored on the lcs storage at the same level of quality which the content entered the lcs domain . optionally , if a watermark is present , the hash may be checked as further verification ; and if the hash matches , the content is allowed in at high quality . if it does not match , the content is rejected . if the extracted watermark does not match the expected watermark , then the content is denied access to the lcs storage ( i . e ., the content is rejected ). in fig3 , content enters the lcs domain from the read - only media . this communication path is identified as path 3 on fig1 . the lcs domain analyzes the content to determine if a watermark is present in the content . if no watermark is present , then the lcs attempts to further analyze the content using other methods ( i . e ., other than watermarking ) to try and verify the content for originality . if the content cannot be verified or is deemed to have been altered , then the content is downgraded to standard quality ( or even low quality ) before it is stored in the lcs storage . if a watermark is present , then the watermark is extracted and compared with the watermark of the lcs in order to determine if a match exists . in the event of a match , or in the event that the content is verified by means other than the watermark , the content is permitted to be stored on the lcs storage at the same level of quality which the content entered the lcs domain ( which is likely to be high quality ). for example , the read - only media may also contain a media - based identifier which verifies the content as an original , as opposed to a copy — and hence , a non - watermark method may be used to verify authenticity . optionally , even in the event of a watermark match , a hash may be checked as further verification ; and if the hash matches , the content is allowed in at high quality , but if there is no match , the content is rejected . if the extracted watermark does not match the expected watermark , or if the lcs is unable to identify any other method for verifying the content &# 39 ; s authenticity , then the content may be denied access to the lcs storage ( i . e ., the content may be rejected ), or if preferred by the user , the content may be permitted into the system at a degraded quality level . it is the user &# 39 ; s prerogative to decide how the system will treat non - authenticated content , as well as legacy content . in fig4 , content enters the lcs domain from the satellite unit . this communication path is identified as path 4 on fig1 . content from an su is marked with an su watermark before exiting the su . the lcs analyzes the content from the su for watermarks , and in particular to determine if there is a watermark that matches that of the lcs . if the watermarks match , the content is permitted access to the lcs at the highest quality level . if there is a mismatch , then the content is denied access ( i . e ., the content is rejected ). if the content does not contain a watermark , the quality is downgraded to low quality before permitting access to the lcs . optionally , even in the event of a watermark match , a hash may be checked as further verification ; and access at the highest quality level may depend upon both a match in watermarks and a match in hashes . in fig5 , content is shown leaving the lcs domain . this communication path is identified as path 5 on fig1 . content is retrieved from the lcs storage and then the content may be watermarked with a watermark that is unique to the lcs ( for example , one that is based upon the lcs &# 39 ; s unique id ). optionally , a hash may be attached to the watermarked content , and / or the hash may be embedded as part of the watermark . if an external hash is used , preferably , for security purposes , the external hash should be created in a different manner from the embedded , watermark hash . optionally , other information may be included in the watermark , for example , information to specify a time stamp , the number of allowable copies , etc . after watermarking , the content may be permitted to exit the lcs domain , and may be exported to a device outside the lcs domain , including for example , a rewritable media , a viewer , player , or other receiver . in fig6 , content is shown leaving the lcs domain . this communication path is identified as path 6 on fig1 . this path is similar to path 5 , with a few important differences . the output receiver is an su , and because the receiver is an su , the content may leave the lcs without being watermarked . path 6 requires a secure protocol to determine that the receiver is in fact an su . once the path is verified , the content can be exported without a watermark . the lcs may optionally transmit the content together with a hash value which will be uniquely associated with the content . in fig7 , content is shown leaving the su , to a receiver other than the lcs . this communication path is identified as path 7 on fig1 . content is retrieved from the su storage and then the content may be watermarked with a watermark that is unique to the su ( for example , one that is based upon the su &# 39 ; s unique id ). optionally , a hash may be attached to the watermarked content , and / or the hash may be embedded as part of the watermark . if an external hash is used , preferably , for security purposes , the external hash should be created in a different manner from the embedded , watermark hash . optionally , other information may be included in the watermark , for example , information to specify a time stamp , the number of allowable copies , etc ., and may even include the hash which the lcs attached to the content after watermarking , the content may be permitted to exit the su , and may be exported to a device other than the lcs , including for example , a rewritable media , a viewer , player , or other receiver . the quality level of the content leaving the lcs is generally the same quality level as that of the content when stored internally to the lcs . the system of the present invention is utilized to complete digital data transactions . a typical transaction would have the following steps : 2 .) the user reviews a collection of data sets which are available for license ( which for purposes of this application , may be equated with a purchase ). the user then selects a data set ( e . g ., a song or other content ), and purchases ( or otherwise obtains the right to receive ) a copy of the data set . ( the user may transmit purchase information , for example , credit card information , using digital security that is known in the art of electronic commerce .) 3 .) the secd transmits the secured content to the lcs . before transmitting any digital content , the secd embeds at least one watermark and may also transmit ( perhaps through cryptography ) at least one hash value along with the data being transmitted . the at least one hash value may be embedded with the at least one watermark or may be attached to the beginning or end of the data being transmitted . alternately , the hash output may be combined in ways that are known in the art . 4 .) the lcs optionally may send its public key to the secd , in which case the secd may use the lcs public key to apply an additional security measure to the data to be transmitted , before the data is actually transmitted to the lcs . 5 .) the lcs receives the secured content transmitted by the secd . the lcs may optionally use its private key to remove the additional layer of security which was applied with the lcs &# 39 ; s public key . 6 .) the lcs may authenticate the secure content that was received from the secd by checking the watermark ( s ) and / or hash values . optionally , the lcs may unpack the secured content from its security wrapper and / or remove any other layers of security . if the content can be authenticated , the content may be accepted into the lcs domain . otherwise , it may be rejected . a fragile watermark — one that is encoded in the lsb of each 16 bit sample — can actually hold all of the data that would typically comprise the information being transmitted in the securechannel ™. at a typical sampling rate of 44 . 1 khz , there is 88 , 200 16 bit samples for each second of data in the time domain ( 44 , 100 . times . 2 stereo channels ). this provides 88 , 200 bits per second which may be used for storing a fragile watermark . a typical 3 minute stereo song could therefore accommodate 1 . 89 mb of data for a fragile watermark . ( the watermark is called fragile , because it is easily removed without greatly sacrificing the quality of the audio data .) 1 . 89 mb represents an immense capacity relative to the expected size of the typical data to be transmitted in a securechannel ( 100 - 200 k ). preferably , the fragile watermark is bound to a specific copy of a specific song , so that “ information pirates ” ( i . e ., would - be thieves ) cannot detect a watermark and then copy it onto another song in an effort to feign authorization when none exists . a fragile watermark may also contain information which can be utilized by various receivers which might receive the signal being packaged . for instance , a fragile watermark may contain information to optimize the playback of a particular song on a particular machine . a particular example could include data which differentiates an mp3 encoded version of a song and an aac encoded version of the same song . one way to bind a fragile watermark to a specific data set is through the use of hash functions . an example is demonstrated by the following sequence of steps : 1 .) a digital data set ( e . g ., a song ) is created by known means ( e . g ., sampling music at 44 . 1 khz , to create a plurality of 16 bit data sets ). the digital data set comprises a plurality of sample sets ( e . g ., a plurality of 16 bit data sets ). 2 .) information relative to the digital data set ( e . g ., information about the version of the song ) is transformed into digital data ( which we will call the securechannel data ), and the securechannel data is then divided into a plurality of securechannel data blocks , each of which blocks may then be separately encoded . 3 .) a first block of the securechannel data is then is encoded into a first block of sample sets ( the first block of sample sets comprising — at a minimum — a sufficient number of sample sets to accommodate the size of the first block of secure channel data ), for example by overwriting the lsb of each sample in the first block of sample sets . 4 .) a hash pool is created comprising the first block of encoded sample sets . 5 .) a first hash value is then created using i ) the hash pool , ii ) a random ( or pseudorandom ) number seeded using a code that serves to identify the owner of the digital data set , and iii ) the securechannel data ; 6 .) the first hash value is then encoded into a second block of sample sets , the second block of sample sets being sufficient in size to accommodate the size of the first hash value . 7 .) the second block of sample sets is then added to the hash pool 8 .) a second block of the securechannel data is then is encoded into a third block of sample sets . 9 .) the third block of encoded sample sets is added to the hash pool . 10 .) a second hash value is then created using i ) the hash pool , ii ) a random ( or pseudorandom ) number seeded using a code that serves to identify the owner of the digital data set , and iii ) the securechannel data ; 11 .) the second hash value is then encoded into a fourth block of sample sets . steps 7 - 11 are then repeated for successive blocks of securechannel data until all of the securechannel data is encoded . understand that for each block of securechannel data , two blocks of content data are utilized . moreover , for efficiency , one could use a predetermined subset of the samples in the hash pool , instead of the whole block . in theory , each securechannel block may be of a different type of block ( i . e ., may begin with a different blockidentifier ). in operation , a software application ( or even an asic ) may read the blockidentifier and determine whether it is a recognized block type for the particular application . if the application does not recognize the block type , the application may use the blocklength to skip this block of securechannel . certain block types will be required to be present if the securechannel is going to be accepted . these might include an identity block and a securechannel hash block . the securechannel data may or may not be encrypted , depending on whether the data is transfer - restricted ( a type of value - adding component , that is , vac ) or simply informative . for instance , user - added securechannel data need not be encrypted . a blockidentifier may also be used to indicate whether a securechannel data block is encrypted or not . a robust - open watermark may be used to divide content into three categories . ( the term “ open watermark ” is used merely to indicate that the watermark relies on a secret which is shared by an entire class of devices , as opposed to a secure watermark — which is readable only by a single member of a class of devices .) a binary setting may be used , whereby one state ( e . g ., “ 1 ”) may be used to identify secure protected content — such as content that is distributed in a secured manner . when the lcs detects a secured status ( e . g ., by determining that the row is “ 1 ”), the content must be accompanied by an authenticatable securechannel before the content is permitted to enter the lcs domain ( e . g ., electronic music distribution or emd content ). the other binary state ( e . g ., “ 0 ”) may be used to identify unsecured content , for example , non - legacy media that is distributed in a pre - packaged form ( e . g . cd &# 39 ; s ). when the binary setting is “ 0 ”, the content may or may not have a securechannel . such “ 0 content ” shall only be admitted from a read - only medium in its original file format ( e . g ., a 0 cd shall only be admitted if it is present on a redbook cd medium ). on the other hand , if the row is absent , then the lcs will understand that the content is “ legacy ”. legacy content may be admitted , or optionally , may be checked for a fragile watermark — and then admitted only if the fragile watermark is present . it would be possible to permit unfettered usage of legacy content — though again , it is the prerogative of the user who sets up the lcs . preferably , a robust forensic watermark is not accessible in any way to the consumer — or to “ information pirates .” a forensic watermark may be secured by a symmetric key held only by the seller . a transaction id may be embedded at the time of purchase with a hash matching the symmetric key . the watermark is then embedded using a very low density insertion mask (& lt ; 10 %), making it very difficult to find without the symmetric key . retrieval of such a watermark is not limited by real - time / low cost constraints . the recovery will typically only be attempted on known pirated material , or material which is suspected of piracy . a recovery time of 2 hours on a 400 mhz pc may , therefore , be reasonable . the system of the present invention contemplates the need for updating and replacing previously - embedded watermarks ( which may be thought of generally as “ renewing ” a watermark ). if someone is able to obtain the algorithms used to embed a watermark — or is otherwise able to crack the security , it would be desirable to be able to embed a new watermark using a secure algorithm . new watermarks , however , cannot be implemented with complete success over night , and thus , there inevitably will be transition periods where older spcs are operating without updated software . in such a transition period , the content must continue to be recognizable to both the old spcss and the upgraded spcss . a solution is to embed both the original and the upgraded watermarks into content during the transition periods . preferably , it is the decision of the content owner to use both techniques or only the upgraded technique . the operation of the system of the present invention is complicated , however , by the presence of “ legacy ” digital content which is already in the hands of consumer ( that is , digital content that was commercially distributed before the advent of watermarking systems ) because legacy content will continue to be present in the future . moreover , pirates who distribute unauthorized content will also complicate matters because such unauthorized copies are likely to be distributed in the same formats as legacy content . as it is unlikely that such unwatermarked content can ever be completely removed , the present system must try to accommodate such content . hardware can be configured to read old row content and extract the old row and insert in the content a new row . while the invention has been particularly shown and described by the foregoing detailed description , it will be understood by those skilled in the art that various other changes in form and detail may be made without departing from the spirit and scope of the invention .