Multi-tier digital TV programming for content distribution6834110Abstract A method of securely providing data to a user's system over a broadcast infrastructure. The method comprising the steps of: encrypting the data using a first encrypting key; encrypting a first decrypting key using a second encrypting key; dividing at least part of the encrypted data into a series of logical packages; placing at least some of the logical packages into a broadcast carousel for cyclical broadcast over the broadcast infrastructure; broadcasting the packages in broadcast carousel so that they can be received by at least one user's system, wherein the broadcast is cyclical and repeats periodically; and transferring the encrypted first decrypting key, which has been encrypted with the second encrypting key, to the user's system. In another embodiment, a system is disclosed to carry out the above method in a broadcast infrastructure and an image overlaid on top of a primary image being displayed isused to denote that additional logical packages are available for receipt by broadcast. Claims What is claimed is: Description CROSS-REFERENCE TO RELATED APPLICATIONS
Cipher Key Size Key Setup Time Encryption Speed
DES 56 460 1,138,519
RC2 40 40 286,888
RC4 40 151 2,377,723
B. Public Key Algorithms In the Secure Digital Content Electronic Distribution System 100, symmetric keys and other small data pieces are encrypted using public keys. Public key algorithms use two keys. The two keys are mathematically related so that data encrypted with one key can only be decrypted with the other key. The owner of the keys keeps one key private (private key) and publicly distributes the second key (public key). To secure the transmission of a confidential message using a public key algorithm, one must use the recipient's public key to encrypt the message. Only the recipient, who has the associated private key, can decrypt the message. Public key algorithms are also used to generate digital signatures. The private key is used for that purpose. The following section provides information on digital signatures. The most common used public-key algorithm is the RSA public-key cipher. It has become the de-facto public key standard in the industry. Other algorithms that also work well for encryption and digital signatures are ElGamal and Rabin. RSA is a variable-key length cipher. Symmetric key algorithms are much faster than the public key algorithms. In software, DES is generally at least 100 times as fast as RSA. Because of this, RSA is not used to encrypt bulk data. RSA Data Security reports that on a 90 MHZ Pentium machine, RSA Data Security's toolkit BSAFE 3.0 has a throughput for private-key operations (encryption or decryption, using the private key) of 21.6 kilobits/second with a 512-bit modules and 7.4 kilobits/second with a 1024-bit modules. C. Digital Signature In the Secure Digital Content Electronic Distribution System 100, the issuer of SC(s) protects the integrity of SC(s) by digitally signing it. In general, to create a digital signature of a message, a message owner first computes the message digest (defined below) and then encrypt the message digest using the owner's private key. The message is distributed with its signature. Any recipient of the message can verify the digital signature first by decrypting the signature using the public key of the message owner to recover the message digest. Then, the recipient computes the digest of the received message and compares it with the recovered one. If the message has not being altered during distribution, the calculated digest and recovered digest must be equal. In the Secure Digital Content Electronic Distribution System 100, since SC(s) contain several data parts, a digest is calculated for each part and a summary digest is calculated for the concatenated part digests. The summary digest is encrypted using the private key of the issuer of the SC(s). The encrypted summary digest is the issuer's digital signature for the SC(s). The part digests and the digital signature are included in the body of the SC(s). The recipients of SC(s) can verify the integrity of the SC(s) and its parts by means of the received digital signature and part digests. A one-way hash algorithm is used to calculate a message digest. A hash algorithm takes a variable-length-input message and converts it into a fixed length string, the message digest. A one-way hash algorithm operates only in one direction. That is, it is easy to calculate the digest for an input message, but it is very difficult (computationally infeasible) to generate the input message from its digest. Because of the properties of the one-way hash functions, one can think of a message digest as a fingerprint of the message. The more common one-way hash functions are MD5 from RSA Data Security and SHA designed by the US National Institute of Technology and Standards (NITS). D. Digital Certificates A digital certificate is used to authenticate or verify the identity of a person or entity that has sent a digitally signed message. A certificate is a digital document issued by a certification authority that binds a public key to a person or entity. The certificate includes the public key, the name of the person or entity, an expiration date, the name of the certification authority, and other information. The certificate also contains the digital signature of the certification authority. When an entity (or person) sends a message signed with its private key and accompanied with its digital certificate, the recipient of the message uses the entity's name from the certificate to decide whether or not to accept the message. In the Secure Digital Content Electronic Distribution System 100, every SC(s), except those issued by the End-User Device(s) 109, includes the certificate of the creator of the SC(s). The End-User Device(s) 109 do not need to include certificates in their SC(s) because many End-User(s) do not bother to acquire a certificate or have certificates issued by non bona-fide Certification Authorities. In the Secure Digital Content Electronic Distribution System 100, the Clearinghouse(s) 105 has the option of issuing certificates to the Electronic Digital Content Store(s) 103. This allows the End-User Device(s) 109 to independently verify that the Electronic Digital Content Store(s) 103 have been authorized by the Secure Digital Content Electronic Distribution System 100. E. Guide To The SC(s) Graphical Representation This document uses a drawing to graphically represent SC(s) that shows encrypted parts, non-encrypted parts, the encryption keys, and certificates. Referring now to FIG. 2 is an example drawing of SC(s) 200. The following symbols are used in the SC(s) figures. Key 201 is a public or private key. The teeth of the key e.g. CLRNGH for Clearinghouse indicate the key owner. PB inside the handle indicates that it is a public key thus key 201 is a Clearinghouse public key. PV inside the handle indicates that it is a private key. Diamond shape is an End-User Digital Signature 202. The initials indicate which private key was used to create the signature thus in EU is the End-User(s) digital signature from table below. Symmetric key 203 is used to encrypt content. An encrypted symmetric key object 204 comprising a symmetric key 203 encrypted with a PB of CLRNGH. The key on the top border of the rectangle is the key used in the encryption of the object. The symbol or text inside the rectangle indicates the encrypted object (a symmetric key in this case). Another encrypted object, in this example a Transaction ID encrypted object 205 is shown. And Usage Conditions 206 for content licensing management as described below. The SC(s) 200 comprises Usage Conditions 206, Transaction ID encrypted object 205, an Application ID encrypted object 207, and encrypted symmetric key object 204, all signed with an End-User Digital Signature 202. The table below shows the initials that identify the signer of SC(s).
Initial Component
CP Content Provider(s) 101
MS Electronic Digital Content Store(s) 103
HS Content Hosting Site(s) 111
EU End-User Device(s) 109
CH Clearinghouse(s) 105
CA certification authority(ies) (not shown)
F. Example of a Secure Container Encryption The tables and diagrams below provide an overview of the encryption and decryption process used to create and recover information from SC(s). The SC(s) that is created and decrypted in this process overview is a general SC(s). It does not represent any of the specific SC(s) types used for rights management in the Secure Digital Content Electronic Distribution System 100. The process consists of the steps described in FIG. 3 for encryption process. Process Flow for Encryption Process of FIG. 3 Step Process 301 Sender generates a random symmetric key and uses it to encrypt the content. 302 Sender runs the encrypted content through a hash algorithm to produce the content digest. 303 Sender encrypts the symmetric key using the recipient's public key. PB RECPNT refers to the recipient's public key. 304 Sender runs the encrypted symmetric key through the same hash algorithm used in step 2 to produce the symmetric key digest. 305 Sender runs the concatenation of the content digest and symmetric key digest through the same hash algorithm used in step 2 to produce the SC(s) digest. 306 Sender encrypts the SC(s) digest with the sender's private key to produce the digital signature for the SC(s). PV SENDER refers to the sender's private key. 307B Sender creates a SC(s) file that includes the encrypted content, encrypted symmetric key, content digest, symmetric key digest, sender's certificate, and SC(s) signature. 307A Sender must have obtained the certificate from a certification authority prior to initiating secure communications. The certification authority includes in the certificate the sender's public key, the sender's name and signs it. PV CAUTHR refers to the certifications authority's private key. Sender transmits the SC(s) to the recipient. Process Flow for Decryption Process of FIG. 4 Step Process 408 Recipient receives the SC(s) and separates its parts. 409 Recipient verifies the digital signature in the sender's certificate by decrypting it with the public key of the certification authority. If the certificate's digital signature is valid, recipient acquires the sender's public key from the certificate. 410 Recipient decrypts the SC(s) digital signature using the sender's public key. This recovers the SC(s) digest. PB SENDER refers to the sender's public key. 411 Recipient runs the concatenation of the received content digest and encrypted key digest through the same hash algorithm used by the sender to compute the SC(s) digest. 412 Recipient compares the computed SC(s) digest with the one recovered from the sender's digital signature. If they are the same, recipient confirms that the received digests have not been altered and continues with the decryption process. If they are not the same, recipient discards the SC(s) and notifies the sender. 413 Recipient runs the encrypted symmetric key through the same hash algorithm used in step 411 to compute the symmetric key digest. 414 Recipient compares the computed symmetric key digest with the one received in the SC(s). If it is the same, recipient knows that the encrypted symmetric key has not been altered. Recipient continues with the decryption process. If not valid, recipient discards the SC(s) and notifies the sender. 415 Recipient runs the encrypted content through the same hash algorithm used in step 411 to compute the content digest. 416 Recipient compares the computed content digest with the one received in the SC(s). If it is the same, recipient knows that the encrypted content has not been altered. Recipient then continues with the decryption process. If not valid, recipient discards the SC(s) and notifies the sender. 417 Recipient decrypts the encrypted symmetric key using the recipient's private key. This recovers the symmetric key. PV RECPNT refers to the recipient's private key. 418 Recipient uses the symmetric key to decrypt the encrypted content. This recovers the content. III. SECURE DIGITAL CONTENT ELECTRONIC DISTRIBUTION SYSTEM FLOW The Secure Electronic Digital Content Distribution System 100, consists of several components that are used by the different participants of the system. These participants include the Content Provider(s) 101, Electronic Digital Content Store(s) 103, End-User(s) via End-User Device(s) 109 and the Clearinghouse(s) 105. A high level system flow is used as an overview of the Secure Digital Content Electronic Distribution System 100. This flow outlined below tracks Content as it flows throughout the System 100. Additionally it outlines the steps used by the participants to conduct the transactions for the purchase, unlocking and use of the Content 113. Some of the assumptions made in the system flow include: This is a system flow for a Digital Content service (Point-to-Point Interface to a PC). Content Provider(s) 101 submits audio Digital Content in PCM uncompressed format (as a music audio example). Content Provider(s) 101 has metadata in an ODBC compliant database or Content Provider(s) 101 will enter the data directly into the Content Information Processing Subsystem, or will have provided data in prescribed ASCII file format(s). Financial settlement is done by the Electronic Digital Content Store(s). Content 113 is hosted at a single Content Hosting Site(s) 111. It should be understood by those skilled in the art that these assumptions can be altered to accommodate the exact nature of the Digital Content e.g. music, video and program and electronic distribution systems broadcast. The following process flow in illustrated in FIG. 1. Step Process 121 A uncompressed PCM audio file is provided as Content 113 by the Content Provider(s) 101. Its filename is input into the Work Flow Manager 154 Tool along with the Content Provider(s)' 101 unique identifier for the Content 113. 122 Metadata is captured from the Content Provider(s)' Database 160 by the Content Information Processing Subsystem using the Content Provider(s)' 101 unique identifier for the Content 113 and information provided by the Database Mapping Template. 123 The Work Flow Manager Tool 154 is used to direct the content flow through the acquisition and preparation process at the Content Provider(s) 101. It can also be used to track the status of any piece of content in the system at any time. 124 The Usage Conditions for the Content 113 are entered into the Content Information Processing Subsystem, this can be done either manually or automatically. This data includes copy restriction rules and any other business rules deemed necessary. All of the metadata entry can occur in parallel with the Audio Processing for the data. 125 The Watermarking Tool is used to hide data in the Content 113 that the Content Provider(s) 101 deems necessary to identify the content. This could include when it was captured, where it came from (this Content Provider(s) 101), or any other information specified by the Content Provider(s) 101. The Content Processing Tool 125 performs equalization, dynamics adjustments and re-sampling to the Content 113 as necessary for the different compression levels supported. The Content 113 is compressed using the Content Processing Tool 125 to the desired compression levels. The Content 113 can then be played back to verify that the compression produces the required level of Content 113 quality. If necessary the equalization, dynamics adjustments, compression and playback quality checks can be performed as many times as desired. The Content 113 and a subset of its metadata is encrypted with a Symmetric Key by the SC Packer. This tool then encrypts the key using the Public Key of the Clearinghouse(s) 105 to produce an Encrypted Symmetric Key. This key can be transmitted anywhere without comprising the security of the Content 113 since the only entity that can decrypt it is the Clearinghouse(s) 105. 126 The Encrypted Symmetric Key, metadata and other information about the Content 113 is then packed into a Metadata SC by the SC Packer Tool 152. 127 The encrypted Content 113 and metadata are then packed into a Content SC. At this point the processing on the Content 113 and metadata is complete. 128 The Metadata SC(s) is then sent to the Content Promotions Web Site 156 using the Content Disbursement Tool (not shown). 129 The Content Disbursement Tool sends the Content SC(s) to the Content Hosting Site(s) 111. The Content Hosting Site(s) can reside at the Content Provider(s) 101, the Clearinghouse(s) 105 or a special location dedicated for Content Hosting. The URL for this site is part of the metadata that was added to the Metadata SC. 130 The Content Promotions Web Site 156 notifies Electronic Digital Content Store(s) 103 of new Content 113 that is added to the System 100. 131 Using the Content Acquisition Tool, Electronic Digital Content Store(s) 103 then download the Metadata SCs that correspond to the Content 113 they wish to sell. 132 The Electronic Digital Content Store(s) 103 will use the Content Acquisition Tool to pull out any data from the Metadata SC(s) that they want to use to promote the Content 113 on their Web Site. Access to portions of this metadata can be secured and charged for if desired. 133 The Usage Conditions for the Content 113, specific to this Electronic Digital Content Store(s) 103, are entered using the Content Acquisition Tool. These Usage Conditions include the retail prices and copy/play restrictions for the different compression levels of the Content 113. 134 The Electronic Digital Content Store(s) 103 specific Usage Conditions and the original Metadata SC(s) are packed into an Offer SC by the SC Packer Tool. 135 After the Electronic Digital Content Store(s) 103 Web Site is updated, the Content 113 is available to End-User(s) surfing the Web. 136 When an End-User(s) finds Content 113 that they want to buy, they click on a content icon, such as a music icon, and the item is added to his/her shopping cart which is maintained by the Electronic Digital Content Store(s) 103. When the End-User(s) completes shopping they submit the purchase request to the Electronic Digital Content Store(s) 103 for processing. 137 The Electronic Digital Content Store(s) 103 then interacts with credit card clearing organizations to place a hold on the funds in the same way they do business today. 138 Once the Electronic Digital Content Store(s) 103 receives the credit card authorization number back from the credit card clearing organization, it stores this into a database and invokes the SC Packer Tool to build a Transaction SC. This Transaction SC includes all of the Offer SCs for the Content 113 that the End-User(s) has purchased, a Transaction ID that can be tracked back to the Electronic Digital Content Store(s) 103, information that identifies the End-User(s), compression levels, Usage Conditions and the price list for the songs purchased. 139 This Transaction SC is then transmitted to the End-User Device(s) 109. 140 When the Transaction SC arrives on the End-User Device(s) 109, it kicks off the End-User Player Application 195 which opens the Transaction SC and acknowledges the End-User's purchase. The End-User Player Application 195 then opens the individual Offer SCs and in an alternate embodiment, may inform the user with an estimate of the download time. It then asks the user to specify when they want to download the Content 113. 141 Based on the time the End-User(s) requested the download, the End-User Player Application 195 will wake up and initiate the start of the download process by building a Order SC that contains among other things the Encrypted Symmetric Key for the Content 1113, the Transaction ID, and End-User(s) information. 142 This Order SC is then sent to the Clearinghouse(s) 105 for processing. 143 The Clearinghouse(s) 105 receives the Order SC, opens it and verifies that none of the data has been tampered with. The Clearinghouse(s) 105 validates the Usage Conditions purchased by the End-User(s). These Usage Conditions must comply with those specified by the Content Provider(s) 101. This information is logged in a database. 144 Once all the checks are complete, the Encrypted Symmetric Key is decrypted using the private key of the Clearinghouse(s) 105. The Symmetric Key is then encrypted using the public key of the End-User(s). This new Encrypted Symmetric Key is then packaged into a License SC by the SC Packer. 145 The License SC is then transmitted to the End-User(s). 146 When the License SC is received at the End-User Device(s) 109 it is stored in memory until the Content SC is downloaded. 147 The End-User Device(s) 109 request from the Content Hosting Facility 111, sending the corresponding License SC for the purchased Content 113. 148 Content 113 is sent to the End-User Device(s) 109. Upon the receipt the Content 113 is de-encrypted by the End-User Device(s) 109 using the Symmetric Key. IV. RIGHTS MANAGEMENT ARCHITECTURE MODEL A. Architecture Layer Functions FIG. 5 is a block diagram of the Rights Management Architecture of the Secure Digital Content Electronic Distribution System 100. Architecturally, four layers represent the Secure Digital Content Electronic Distribution System 100: the License Control Layer 501, the Content Identification Layer 503, Content Usage Control Layer 505, and the Content Formatting Layer 507. The overall functional objective of each layer and the individual key functions for each layer are described in this section. The functions in each of the layers are fairly independent of the functions in the other layers. Within broad limitations, functions in a layer can be substituted with similar functions without affecting the functionality of the other layers. Obviously, it is required that the output from one layer satisfies format and semantics acceptable to the adjacent layer. The License Control Layer 501 ensures that: the Digital Content is protected during distribution against illegal interception and tampering; the Content 113 originates from a rightful content owner and is distributed by a licensed distributor, e.g. Electronic Digital Content Store(s) 103; the Digital Content purchaser has a properly licensed application; the distributor is paid by the purchaser before a copy of the Content 113 is made available to the purchaser or End-User(s); and a record of the transaction is kept for reporting purposes. The Content Identification Layer 503 allows for the verification of the copyright and the identity of the content purchaser. The content's copyright information and identity of the content purchaser enables the source tracking of any, authorized or not, copy of the Content 113. Thus, the Content Identification Layer 503 provides a means to combat piracy. The Content Usage Control Layer 505 ensures that the copy of the Content 113 is used in the purchaser's device according to the Store Usage Conditions 519. The Store Usage Conditions 519 may specify the number of plays and local copies allowed for the Content 113, and whether or not the Content 113 may be recorded to an external portable device. The functions in the Content Usage Control Layer 505 keep track of the content's copy/play usage and update the copy/play status. The Content Formatting Layer 507 allows for the format conversion of the Content 113 from its native representation in the content owner's facilities into a form that is consistent with the service features and distribution means of the Secure Digital Content Electronic Distribution System 100. The conversion processing may include compression encoding and its associated preprocessing, such as frequency equalization and amplitude dynamic adjustment. For Content 113 which is audio, at the purchaser's side, the received Content 113 also needs to be processed to achieve a format appropriate for playback or transfer to a portable device. B. Function Partitioning and Flows The Rights Management Architectural Model is shown in FIG. 5 and this illustrates the mapping of the architectural layers to the operating components making up the Secure Digital Content Electronic Distribution System 100 and the key functions in each layer. 1. Content Formatting Layer 507 The general functions associated with the Content Formatting Layer 507 are Content Preprocessing 502 and Compression 511 at the Content Provider(s) 101, and Content De-scrambling 513 and Decompression 515 at the End-User Device(s) 109. The need for preprocessing and the examples of specific functions were mentioned above. Content Compression 511 is used to reduce the file size of the Content 113 and its transmission time. Any compression algorithm appropriate for the type of Content 113 and transmission medium can be used in the Secure Digital Content Electronic Distribution System 100. For music, MPEG 1/2/4, Dolby AC-2 and AC-3, Sony Adaptive Transform Coding (ATRAC), and low-bit rate algorithms are some of the typically used compression algorithms. The Content 113 is stored in the End-User Device(s) 109 in compressed form to reduce the storage size requirement. It is decompressed during active playback. De-scrambling is also performed during active playback. The purpose and type of scrambling will be described later during the discussion of the Content Usage Control Layer 505. 2. Content Usage Control Layer 505 The Content Usage Control Layer 505 permits the specification and enforcement of the conditions or restrictions imposed on the use of Content 113 use at the End-User Device(s) 109. The conditions may specify the number of plays allowed for the Content 113, whether or not a secondary copy of the Content 113 is allowed, the number of secondary copies, and whether or not the Content 113 may be copied to an external portable device. The Content Provider(s) 101 sets the allowable Usage Conditions 517 and transmits them to the Electronic Digital Content Store(s) 103 in a SC (see the License Control Layer 501 section). The Electronic Digital Content Store(s) 103 can add to or narrow the Usage Conditions 517 as long as it doesn't invalidate the original conditions set by the Content Provider(s) 101. The Electronic Digital Content Store(s) 103 then transmits all Store Usage Conditions 519 (in a SC) to the End-User Device(s) 109 and the Clearinghouse(s) 105. The Clearinghouse(s) 105 perform Usage Conditions Validation 521 before authorizing the Content 113 release to an End-User Device(s) 109. The enforcement of the content Usage Conditions 517 is performed by the Content Usage Control Layer 505 in the End-User Device(s) 109. First, upon reception of the Content 113 copy from the Content Identification Layer 503 in the End-User Device(s) 109 marks the Content 113 with a Copy/Play Code 523 representing the initial copy/play permission. Second, the Player Application 195 cryptographically scrambles the Content 113 before storing it in the End-User Device(s) 109. The Player Application 195 generates a scrambling key for each Content item, and the key is encrypted and hidden in the End-User Device(s) 109. Then, every time the End-User Device(s) 109 accesses the Content 113 for copy or play, the End-User Device(s) 109 verifies the copy/play code before allowing the de-scrambling of the Content 113 and the execution of the play or copy. The End-User Device(s) 109 also appropriately updates the copy/play code in the original copy of the Content 113 and on any new secondary copy. The copy/play coding is performed on Content 113 that has been compressed. That is, there is no need to decompress the Content 113 before the embedding of the copy/play code. The End-User Device(s) 109 uses a License Watermark 527 to embed the copy/play code within the Content 113. Only the End-User Player Application 195 that is knowledgeable of the embedding algorithm and the associated scrambling key is able to read or modify the embedded data. The data is invisible or inaudible to a human observer; that is, the data introduces no perceivable degradation to the Content 113. Since the watermark survives several steps of content processing, data compression, D-to-A and A-to-D conversion, and signal degradation introduced by normal content handling, the watermark stays with the Content 113 in any representation form, including analog representation. In an alternate embodiment, instead of using a License Watermark 527 to embed the copy/play code within the Content 113, the End-User Player Application 195 uses securely stored Usage Conditions 519. 3. Content Identification Layer 503 As part of the Content Identification Layer 503, the Content Provider(s) 101 also uses a License Watermark 527 to embed data in the Content 113 such as to the content identifier, content owner and other information, such as publication date and geographic distribution region. This watermark is referred to here as the Copyright Watermark 529. Upon reception, the End-User Device(s) 109 watermarks the copy of the Content 113 with the content purchaser's name and the Transaction ID 535 (see the License Control Layer 501 section below), and with other information such as date of license and Usage Conditions 517. This watermark is referred to here as the license watermark. Any copy of Content 113, obtained in an authorized manner or not, and subject to audio processing that preserves the content quality, carries the copyright and license watermarks. The Content Identification Layer 503 deters piracy. 4. License Control Layer 501 The License Control Layer 501 protects the Content 113 against unauthorized interception and ensures that the Content is only released on an individual basis to an End-User(s) that has properly licensed End-User Device(s) 109 and successfully completes a license purchase transaction with an authorized Electronic Digital Content Store(s) 103. The License Control Layer 501 protects the Content 113 by double Encryption 531. The Content 113 is encrypted using an encryption symmetric key generated by the Content Provider(s) 101, and the symmetric key is encrypted using the public key 621 of the Clearinghouse(s). Only the Clearinghouse(s) 105 can initially recover the symmetric key. License control is designed with the Clearinghouse(s) 105 as the "trusted party". Before releasing permission for the License Request 537, (i.e. the Symmetric Key 623 for the Content 113 to an End-User Device(s) 109), the Clearinghouse(s) 105 verifies that the Transaction 541 and the License Authorization 543 are complete and authentic, that the Electronic Digital Content Store(s) 103 has authorization from the Secure Digital Content Electronic Distribution System 100 for the sale of electronic Content 113, and that the End-User(s) has a properly licensed application. Audit/Reporting 545 allows the generation of reports and the sharing of licensing transaction information with other authorized parties in the Secure Electronic Digital Content Distribution System 100. License control is implemented through SC Processing 533. SC(s) are used to distribute encrypted Content 113 and information among the system operation components (more about the SC(s) detailed structure sections below). A SC is cryptographic carrier of information that uses cryptographic encryption, digital signatures and digital certificates to provide protection against unauthorized interception and modification of the electronic information or Content 113. It also allows for the authenticity verification of the electronic data. License control requires that the Content Provider(s) 101, the Electronic Digital Content Store(s) 103, and the Clearinghouse(s) 105 have bona-fide cryptographic digital certificates from reputable Certificate Authorities that are used to authenticate those components. The End-User Device(s) 109 are not required to have digital certificates. C. Content Distribution and Licensing Control FIG. 6 is a block diagram illustrating an overview of the Content Distribution and Licensing Control as it applies to the License Control Layer of FIG. 5. The figure depicts the case in which the Electronic Digital Content Store(s) 103, End-User Device(s) 109 and the Clearinghouse(s) 105 are interconnected via the Internet, and unicast (point-to-point) transmission is used among those components. The communication between the Content Provider(s) 101 and the Electronic Digital Content Store(s) 103 could also be over the Internet or other network. It is assumed that the Content-purchase commercial transaction between the End-User Device(s) 109 and the Electronic Digital Content Store(s) 103 is based on standard Internet Web protocols. As part of the Web-based interaction, the End-User(s) makes the selection of the Content 113 to purchase, provides personal and financial information, and agrees to the conditions of purchase. The Electronic Digital Content Store(s) 103 could obtain payment authorization from an acquirer institutionusing a protocol such as SET. It is also assumed in FIG. 6 that the Electronic Digital Content Store(s) 103 has downloaded the End-User Player Application 195 to an End-User Device(s) 109 based on standard Web protocols. The architecture requires that the Electronic Digital Content Store(s) 103 assigns a unique application ID to the downloaded Player Application 195 and that the End-User Device(s) 109 stores it for later application license verification (see below). The overall licensing flow starts at the Content Provider(s) 101. The Content Provider(s) 101 encrypts the Content 113 using an encryption symmetric key locally generated, and encrypts the Symmetric Key 623 using the Clearinghouse's 105 public key 621. In an alternate embodiment, the symmetric key instead of being locally generated my be sent to the Content Provider(s) 101 from the Clearinghouse(s) 105. The Content Provider(s) 101 creates a Content SC(s) 630 around the encrypted Content 113, and a Metadata SC(s) 620 around the encrypted Symmetric Key 623, Store Usage Conditions 519, and other Content 113 associated information. There is one Metadata SC(s) 620 and one Content SC(s) 630 for every Content 113 object. The Content 113 object may be a compression level one same song or the Content 113 object may be each song on the album or the Content 113 object may be the entire album. For each Content 113 object, the Metadata SC(s) 620 also carries the Store Usage Conditions 519 associated with the Content Usage Control Layer 505. The Content Provider(s) 101 distributes the Metadata SC(s) 620 to one or more Electronic Digital Content Store(s) 103 (step 601) and the Content SC(s) 630 to one or more Content Hosting Sites (step 602). Each Electronic Digital Content Store(s) 103, in turn creates an Offer SC(s) 641. The Offer SC(s) 641 typically carries much of the same information as the Metadata SC(s) 620, including the Digital Signature 624 of the Content Provider(s) 101 and the Certificate (not shown of the Content Provider(s) 101. As mentioned above, the Electronic Digital Content Store(s) 103 can add to or narrow the Store Usage Conditions 519 (handled by the Control Usage Control Layer) initially defined by the Content Provider(s) 101. Optionally, the Content SC(s) 630 and/or the Metadata SC(s) 620 is signed with a Digital Signature 624 of the Content Provider(s) 101. After the completion of the Content-purchase transaction between the End-User Device(s) 109 and the Electronic Digital Content Store(s) 103 (step 603), the Electronic Digital Content Store(s) 103 creates and transfers to the End-User Device(s) 109 a Transaction SC(s) 640 (step 604). The Transaction SC(s) 640 includes a unique Transaction ID 535, the purchaser's name (i.e. End-User(s)') (not shown), the Public Key 661 of the End-User Device(s) 109, and the Offer SC(s) 641 associated with the purchased Content 113. Transaction Data 642 in FIG. 6 represents both the Transaction ID 535 and the End-User(s) name (not shown). The Transaction Data 642 is encrypted with the Public Key 621 of the Clearinghouse(s) 105. Optionally, the Transaction SC(s) 640 is signed with a Digital Signature 643 of the Electronic Digital Content Store(s) 103. Upon reception of the Transaction SC(s) 640 (and the Offer SC(s) 641 included in it), the End-User Player Application 195 running on End-User Device(s) 109 solicits license authorization from the Clearinghouse(s) 105 by means of an Order SC(s) 650 (step 605). The Order SC(s) 650 includes the encrypted Symmetric Key 623 and Store Usage Conditions 519 from the Offer SC(s) 641, the encrypted Transaction Data 642 from the Transaction SC(s) 640, and the encrypted Application ID 551 from the End-User Device(s) 109. In another embodiment, the Order SC(s) 650 is signed with a Digital Signature 652 of the End-User Device(s) 109. Upon reception of the Order SC(s) 650 from the End-User Device(s) 109, the Clearinghouse(s) 105 verifies: that the Electronic Digital Content Store(s) 103 has authorization from the Secure Digital Content Electronic Distribution System 100 (exists in the Database 160 of the Clearinghouse(s) 105); 2. that the Order SC(s) 650 has not been altered; 3. that the Transaction Data 642 and Symmetric Key 623 are complete and authentic; 4. that the electronic Store Usage Conditions 519 purchased by the End-User Device(s) 109 are consistent with those Usage Conditions 517 set by the Content Provider(s) 101; and 5. that the Application ID 551 has a valid structure and that it was provided by an authorized Electronic Digital Content Store(s) 103. If the verifications are successful, the Clearinghouse(s) 105 decrypts the Symmetric Key 623 and the Transaction Data 642 and builds and transfers the License SC(s) 660 to the End-User Device(s) 109 (step 606). The License SC(s) 660 carries the Symmetric Key 623 and the Transaction Data 642, both encrypted using the Public Key 661 of the End-User Device(s) 109. If any verification is not successful, the Clearinghouse(s) 105 denies the license to the End-User Device(s) 109 and informs the End-User Device(s) 109. The Clearinghouse(s) 105 also immediately informs the Electronic Digital Content Store(s) 103 of this verification failure. In an alternate embodiment, the Clearinghouse(s) 105 signs the License SC(s) 660 with its Digital Signature 663. After receiving the License SC(s) 660, the End-User Device(s) 109 decrypts the Symmetric Key 623 and the Transaction Data 642 previously received from the Clearinghouse(s) 105 and requests the Content SC(s) 630 (step 607) from a Content Hosting Site(s) 111. Upon arrival of the Content SC(s) 630 (step 608), the End-User Device(s) 109 decrypts the Content 113 using the Symmetric Key 623 (step 609), and passes the Content 113 and the Transaction Data 642 to the other layers for license Watermarking, copy/play coding, scrambling, and further Content 113 processing as described previously for FIG. 5. Finally, the Clearinghouse(s) 105 on a periodic basis transmits summary transaction reports to the Content Provider(s) 101 and the Electronic Digital Content Store(s) 103 for auditing and tracking purposes (step 610). V. SECURE CONTAINER STRUCTURE A. General Structure A Secure Container (SC) is a structure that consists of several parts which together define a unit of Content 113 or a portion of a transaction, and which also define related information such as Usage Conditions, metadata, and encryption methods. SC(s) are designed in such a way that the integrity, completeness, and authenticity of the information can be verified. Some of the information in SC(s) may be encrypted so that it can only be accessed after proper authorization has been obtained. SC(s) include at least one bill of materials (BOM) part which has records of information about the SC(s) and about each of the parts included in the SC(s). A message digest is calculated, using a hashing algorithm such as MD-5, for each part and then included in the BOM record for the part. The digests of the parts are concatenated together and another digest is computed from them and then encrypted using the private key of the entity creating the SC(s) to create a digital signature. Parties receiving the SC(s) can use the digital signature to verify all of the digests and thus validate the integrity and completeness of the SC(s) and all of its parts. The following information may be included as records in the BOM along with the records for each part. The SC(s) type determines which records need to be included: SC(s) version SC(s) ID Type of SC(s) (e.g. Offer, Order, Transaction, Content, Metadata or promotional and License.) Publisher of the SC(s) Date that the SC(s) was created Expiration date of the SC(s)= Clearinghouse(s) URL Description of the digest algorithm used for the included parts (default is MD-5) Description of the algorithm used for the digital signature encryption (default is RSA) Digital signature (encrypted digest of all of the concatenated digests of the included parts) SC(s) may include more than one BOM. For example, an Offer SC(s) 641 consists of the original Metadata SC(s) 620 parts, including its BOM, as well as additional information added by the Electronic Digital Content Store(s) 103 and a new BOM. A record for the Metadata SC(s) 620 BOM is included in the Offer SC(s) 641 BOM. This record includes a digest for the Metadata SC(s) 620 BOM which can be used to validate its integrity and therefore, the integrity of the parts included from the Metadata SC(s) 620 can also be validated using the part digest values stored in Metadata SC(s) 620 BOM. None of the parts from the Metadata SC(s) 620 have records in the new BOM that was created for the Offer SC(s) 641. Only parts added by the Electronic Digital Content Store(s) 103 and the Metadata SC(s) 620 BOM have records in the new BOM. SC(s) may also include a Key Description part. Key Description parts include records that contain the following information about encrypted parts in the SC(s): The name of the encrypted part. The name to use for the part when it is decrypted. The encryption algorithm used to encrypt the part. Either a Key Identifier to indicate the public encryption key that was used to encrypt the part or an encrypted symmetric key that, when decrypted, is used to decrypt the encrypted part. The encryption algorithm used to encrypt the symmetric key. This field is only present when the record in the Key Description part includes an encrypted symmetric key that was used to encrypt the encrypted part. A Key Identifier of the public encryption key that was used to encrypt the symmetric key. This field is only present when the record in the Key Description part includes an encrypted symmetric key and the encryption algorithm identifier of the symmetric key that was used to encrypt the encrypted part. If the SC(s) does not contain any encrypted parts, then there is no Key Description part. B. Rights Management Language Syntax and Semantics The Rights Management Language consists of parameters that can be assigned values to define restrictions on the use of the Content 113 by an End-User(s) after the Content 113 purchase. The restrictions on the use of the Content 113 is the Usage Conditions 517. Each Content Provider(s) 101 specifies the Usage Conditions 517 for each of its Content 113 items. Electronic Digital Content Store(s) 103 interpret the Usage Conditions 517 in Metadata SC(s) 620 and use the information to provide select options they wish to offer their customers as well as add retail purchase information for the Content 113. After an End-User(s) has selected a Content 113 item for purchase, the End-User Device(s) 109 requests authorization for the Content 113 based on Store Usage Conditions 519. Before the Clearinghouse(s) 105 sends a License SC(s) 660 to the End-User(s), the Clearinghouse(s) 105 verifies that the Store Usage Conditions 519 being requested are in agreement with the allowable Usage Conditions 517 that were specified by the Content Provider(s) 101 in the Metadata SC(s) 620. When an End-User Device(s) 109 receives the Content 113 that was purchased, the Store Usage Conditions 519 are encoded into that Content 113 using the Watermarking Tool or encoded in the securely stored Usage Conditions 519. The End-User Player Application 195 running on End-User Device(s) 109 insures that the Store Usage Conditions 519 that were encoded into the Content 113 are enforced. The following are examples of Store Usage Conditions 519 for an embodiment where the Content 113 is music: Song is recordable. Song can be played n number of times. C. Overview of Secure Container Flow and Processing Metadata SC(s) 620 are built by Content Provider(s) 101 and are used to define Content 113 items such as songs. The Content 113 itself is not included in these SC(s) because the size of the Content 113 is typically too large for Electronic Digital Content Store(s) 103 and End-User(s) to efficiently download the containers just for the purpose of accessing the descriptive metadata. Instead, the SC(s) includes an external URL (Uniform Resource Locators) to point to the Content 113. The SC(s) also includes metadata that provides descriptive information about the Content 113 and any other associated data, such as for music, the CD cover art and/or digital audio clips in the case of song Content 113. Electronic Digital Content Store(s) 103 download the Metadata SC(s) 620, for which they are authorized, and build Offer SC(s) 641. In short, an Offer SC(s) 641 consists of some of the parts and the BOM from the Metadata SC(s) 620 along with additional information included by the Electronic Digital Content Store(s) 103. A new BOM for the Offer SC(s) 641 is created when the Offer SC(s) 641 is built. Electronic Digital Content Store(s) 103 also use the Metadata SC(s) 620 by extracting metadata information from them to build HTML pages on their web sites that present descriptions of Content 113 to End-User(s), usually so they can purchase the Content 113. The information in the Offer SC(s) 641 that is added by the Electronic Digital Content Store(s) 103 is typically to narrow the selection of Usage Conditions 517 that are specified in the Metadata SC(s) 620 and promotional data such as a graphic image file of the store's logo and a URL to the store's web site. An Offer SC(s) 641 template in the Metadata SC(s) 620 indicates which information can be overridden by the Electronic Digital Content Store(s) 103 in the Offer SC(s) 641 and what, if any, additional information is required by the Electronic Digital Content Store(s) 103 and what parts are retained in the embedded Metadata SC(s) 620. Offer SC(s) 641 are included in a Transaction SC(s) 640 when an End-User(s) decides to purchase Content 113 from an Electronic Digital Content Store(s) 103. The Electronic Digital Content Store(s) 103 builds a Transaction SC(s) 640 and includes Offer SC(s) 641 for each Content 113 item being purchased and transmits it to the End-User Device(s) 109. The End-User Device(s) 109 receives the Transaction SC(s) 640 and validates the integrity of the Transaction SC(s) 640 and the included Offer SC(s) 641. An Order SC(s) 650 is built by the End-User Device(s) 109 for each Content 113 item being purchased. Information is included from the Offer SC(s) 641, from the Transaction SC(s) 640, and from the configuration files of the End-User Device(s) 109. Order SC(s) 650 are sent to the Clearinghouse(s) 105 one at a time. The Clearinghouse(s) 105 URL where the Order SC(s) 650 is included as one of the records in the BOM for the Metadata SC(s) 620 and included again in the Offer SC(s) 641. The Clearinghouse(s) 105 validates and processes Order SC(s) 650 to provide the End-User Device(s) 109 with everything that is required to a License Watermark 527 and access purchased Content 113. One of the functions of the Clearinghouse(s) 105 is to decrypt the Symmetric Keys 623 that are needed to decrypt the watermarking instructions from the Offer SC(s) 641 and the Content 113 from the Content SC(s) 630. An encrypted Symmetric Key 623 record actually contains more than the actual encrypted Symmetric Key 623. Before executing the encryption, the Content Provider(s) 101 may optionally append its name to the actual Symmetric Key 623. Having the Content Provider(s)' 101 name encrypted together with the Symmetric Key 623 provides security against a pirate Content Provider(s) 101 that has built its own Metadata SC(s) 620 and Content SC(s) 630 from legal SC(s). The Clearinghouse(s) 105 verifies that the name of the Content Provider(s) 101 encrypted together with the Symmetric Keys 623 matches the name of the Content Provider(s) 101 in the SC(s) certificate. If there are any changes required to be made to the watermarking instructions by the Clearinghouse(s) 105, then the Clearinghouse(s) 105 decrypts the Symmetric Key 623 and then modifies the watermarking instructions and encrypts them again using a new Symmetric Key 623. The Symmetric Key 623 is then re-encrypted using the Public Key 661 of the End-User Device(s) 109. The Clearinghouse(s) 105 also decrypts the other Symmetric Keys 623 in the SC(s) and encrypts them again with the Public Key 661 of the End-User Device(s) 109. The Clearinghouse(s) 105 builds a License SC(s) 660 that includes the newly encrypted Symmetric Keys 623 and updated watermarking instructions and sends it to the End-User Device(s) 109 in response to the Order SC(s) 650. If the processing of the Order SC(s) 650 does not complete successfully, then the Clearinghouse(s) 105 returns to the End-User Device(s) 109 an HTML page or equivalent reporting the failure of the authorization process. A License SC(s) 660 provides an End-User Device(s) 109 with everything that is needed to access a Content 113 item. The End-User Device(s) 109 requests the appropriate Content SC(s) 630 from the Content Hosting Site(s) 111. Content SC(s) 630 are built by Content Provider(s) 101 and include encrypted Content 113 and metadata parts. The End-User Player Application 195 uses the Symmetric Keys 623 from the License SC(s) 660 to decrypt the Content 113, metadata, and watermarking instructions. The watermarking instructions are then affixed into the Content 113 and the Content 113 is scrambled and stored on the End-User Device(s) 109. D. Metadata Secure Container 620 Format The following table shows the parts that are included in a Metadata SC(s) 620. Each box in the Parts column is a separate object included in the SC(s) along with the BOM (with the exception of part names that are surrounded by [ ] characters). The BOM contains a record for each part included in the SC(s). The Part Exists column indicates whether the part itself is actually included in the SC(s) and the Digest column indicates whether a message digest is computed for the part. Some parts may not be propagated when a SC(s) is included in other SC(s) (as determined by the associated template), although the entire original BOM is propagated. This is done because the entire BOM is required by the Clearinghouse(s) 105 to verify the digital signature in the original SC(s). The Key Description Part columns of the following table define the records that are included in the Key Description part of the SC(s). Records in the Key Description part define information about the encryption keys and algorithms that were used to encrypt parts within the SC(s) or parts within another SC(s). Each record includes the encrypted part name and, if necessary, a URL that points to another SC(s) that includes the encrypted part. The Result Name column defines the name that is assigned to the part after it is decrypted. The Encrypt Alg column defines the encryption algorithm that was used to encrypt the part. The Key Id/Enc Key column defines either an identification of the encryption key that was used to encrypt the part or a base64 encoding of the encrypted Symmetric Key 623 bit string that was used to encrypt the part The Sym Key Alg column is an optional parameter that defines the encryption algorithm that was used to encrypt the Symmetric Key 623 when the previous column is an encrypted Symmetric Key 623. The Sym Key ID column is an identification of the encryption key that was used to encrypt the Symmetric Key 623 when the Key Id/Enc Key column is an encrypted Symmetric Key 623.
BOM Key
Description Part
Parts Part Exists Digest Result Name Encrypt Alg
Key Id/Enc Key Sym Key Alg Sym Key ID
[Content URL] Output Part RC4 Enc
Sym Key RSA CH Pub Key
[Metadata URL] Output Part RC4 Enc
Sym Key RSA CH Pub Key
SC Version
SC ID
SC Type
SC Publisher
Date
Expiration Date
Clearinghouse(s) URL
Digest Algorithm ID
Digital Signature Alg ID
Content ID Yes Yes
Metadata Yes Yes
Usage Conditions Yes Yes
SC Templates Yes Yes
Watermarking Instructions Yes Yes Output Part RC4
Enc Sym Key RSA CH Pub Key
Key Description Part Yes Yes
Clearinghouse(s) Certificate(s) Yes No
Certificate(s) Yes No
Digital Signature
The following describes the terms that are used in the above Metadata SC(s) table: [Content URL]--A parameter in a record in the Key Description part. This is a URL that points to the encrypted Content 113 in the Content SC(s) 630 that is associated with this Metadata SC(s) 620. The Metadata SC(s) 620 itself does not contain the encrypted Content 113. [Metadata URL]--A parameter in a record in the Key Description part. This is a URL that points to the encrypted metadata in the Content SC(s) 630 that is associated with this Metadata SC(s) 620. The Metadata SC(s) 620 itself does not contain the encrypted metadata. Content ID --A part that defines a unique ID assigned to a Content 113 item. There is more than one Content ID included in this part if the Metadata SC(s) 620 references more than one Content 113 item. Metadata --Parts that contain information related to a Content 113 item such as the artist name and CD cover art in the case of a song. There may be multiple metadata parts, some of which may be encrypted. The internal structure of the metadata parts is dependent on the type of metadata contained therein. Usage Conditions --A part that contains information that describes usage options, rules, and restrictions to be imposed on an End-User(s) for use of the Content 113. SC(s) Templates --Parts that define templates that describe the required and optional information for building the Offer, Order, and License SC(s) 660. Watermarking Instructions --A part that contains the encrypted instructions and parameters for implementing watermarking in the Content 113. The watermarking instructions may be modified by the Clearinghouse(s) 105 and returned back to the End-User Device(s) 109 within the License SC(s) 660. There is a record in the Key Description part that defines the encryption algorithm that was used to encrypt the watermarking instructions, the output part name to use when the watermarking instructions are decrypted, a base64 encoding of the encrypted Symmetric Key 623 bit string that is was used to encrypt the watermarking instructions, the encryption algorithm that was used to encrypt the Symmetric Key 623, and the identification of the public key that is required to decrypt the Symmetric Key 623. Clearinghouse(s) Certificate(s)--A certificate from a certification authority or from the Clearinghouse(s) 105 that contains the signed Public Key 621 of the Clearinghouse(s) 105. There may be more than one certificate, in which case a hierarchical level structure is used with the highest level certificate containing the public key to open the next lowest level certificate is reached which contains the Public Key 621 of the Clearinghouse(s) 105. Certificate(s)--A certificate from a certification authority or from the Clearinghouse(s) 105 that contains the signed Public Key 621 of the entity that created the SC(s). There may be more than one certificate, in which case a hierarchical level structure is used with the highest level certificate containing the public key to open the next level certificate, and so on, until the lowest level certificate is reached which contains the public key of the SC(s) creator. SC Version--A version number assigned to the SC(s) by the SC Packer Tool. SC ID--A unique ID assigned to the SC(s) by the entity that created the SC(s). SC Type--Indicates the type of SC(s) (e.g. Metadata, Offer, Order, etc.) SC Publisher--Indicates the entity that created the SC(s). Creation Date--Date that the SC(s) was created. Expiration Date--Date the SC(s) expires and is no longer valid. Clearinghouse(s) URL --Address of the Clearinghouse(s) 105 that the End-User Player Application 195 should interact with to obtain the proper authorization to access the Content 113. Digest Algorithm ID--An identifier of the algorithm used to compute the digests of the parts. Digital Signature Alg ID--An identifier of the algorithm used to encrypt the digest of the concatenated part digests. This encrypted value is the digital signature. Digital Signature--A digest of the concatenated part digests encrypted with the public key of the entity that created the SC(s). Output Part--The name to assign to the output part when an encrypted part is decrypted. RSA and RC4--Default encryption algorithms used to encrypt the Symmetric Keys 623 and data parts. Enc Sym Key--A base64 encoding of an encrypted key bitstring that, when decrypted, is used to decrypt a SC(s) part. CH Pub Key--An identifier that indicates that the Clearinghouse's 105 Public Key 621 was used to encrypt the data. E. Offer Secure Container 641 Format The following table shows the parts that are included in the Offer SC(s) 641. The parts, with the exception of some of the metadata parts, and BOM from the Metadata SC(s) 620 are also included in the Offer SC(s) 641.
BOM Key
Description Part
Parts Part Exists Digest Result Name Encrypt Alg
Key Id/Enc Key Sym Key Alg Sym Key ID
Metadata SC Parts
[Content URL] Output Part RC4 Enc
Sym Key RSA CH Pub Key
[Metadata URL] Output Part RC4 Enc
Sym Key RSA CH Pub Key
SC Version
SC ID
SC Type
SC Publisher
Date
Expiration Date
Clearinghouse(s) URL
Digest Algorithm ID
Digital Signature Alg ID
Content ID Yes Yes
Metadata Some Yes
Usage Conditions Yes Yes
SC Templates Yes Yes
Watermarking Instructions Yes Yes Output Part RC4
Enc Sym Key RSA CH Pub Key
Key Description Part Yes Yes
Clearinghouse(s) Certificate(s) Yes No
Certificate(s) Yes No
Digital Signature
Offer SC Parts
SC Version
SC ID
SC Type
SC Publisher
Date
Expiration Date
Digest Algorithm ID
Digital Signature Alg ID
Metadata SC BOM Yes Yes
Additional and Overridden Yes Yes
Fields
Electronic Digital Content Yes No
Store(s) Certificate
Certificate(s) Yes No
Digital Signature
The following describes the terms that are used in the above Offer SC(s) 641 that were not previously described for another SC(s): Metadata SC(s) BOM--The BOM from the original Metadata SC(s) 620. The record in the Offer SC(s) 641 BOM includes the digest of the Metadata SC(s) 620 BOM. Additional and Overridden Fields--Usage conditions information that was overridden by the Electronic Digital Content Store(s) 103. This information is validated by the Clearinghouse(s) 105, by means of the received SC(s) templates, to make sure that anything that the Electronic Digital Content Store(s) 103 overrides is within the scope of its authorization. Electronic Digital Content Store(s) Certificate--A certificate provided to the Electronic Digital Content Store(s) 103 by the Clearinghouse(s) 105 and signed by the Clearinghouse(s) 105 using its private key. This certificate is used by the End-User Player Application 195 to verify that the Electronic Digital Content Store(s) 103 is a valid distributor of Content 113. The End-User Player Application 195 and Clearinghouse(s) 105 can verify that the Electronic Digital Content Store(s) 103 is an authorized distributor by decrypting the certificate's signature with the Clearinghouse's 105 Public Key 621. The End-User Player Application 195 keeps a local copy of the Clearinghouse's 105 Public Key 621 that it receives as part of its initialization during installation. F. Transaction Secure Container 640 Format The following table shows the parts that are included in t | ||||||