Source: https://patents.google.com/patent/EP0798892B1/en
Timestamp: 2019-10-23 10:44:36
Document Index: 167885103

Matched Legal Cases: ['art 203', 'arts 209', 'arts 208', 'arts 209', 'art 301', 'arts 203', 'arts 209', 'arts 601']

EP0798892B1 - Creation and distribution of digital documents - Google Patents
Creation and distribution of digital documents Download PDF
EP0798892B1
EP0798892B1 EP19970301307 EP97301307A EP0798892B1 EP 0798892 B1 EP0798892 B1 EP 0798892B1 EP 19970301307 EP19970301307 EP 19970301307 EP 97301307 A EP97301307 A EP 97301307A EP 0798892 B1 EP0798892 B1 EP 0798892B1
EP19970301307
EP0798892A3 (en
EP0798892A2 (en
1996-03-29 Priority to US625475 priority Critical
1997-02-27 Application filed by International Business Machines Corp filed Critical International Business Machines Corp
1997-10-01 Publication of EP0798892A2 publication Critical patent/EP0798892A2/en
2000-04-26 Publication of EP0798892A3 publication Critical patent/EP0798892A3/en
2006-07-12 Publication of EP0798892B1 publication Critical patent/EP0798892B1/en
This invention is related to a method for the creation and distribution, of digital documents in particular using the methods and techniques of secure cryptographic envelopes. The invention also relates to a method for the sale and controlled access of digital documents using the same methods and techniques.
US Patent publication 5,319,705 discloses a method and system for securely distributing a plurality of software files from a software distribution server to a user client, while selectively enabling the user client to use a subset of a lesser plurality of the software files. An important distinction between our work and Ref.2 is that in our disclosure the part encryption key is carried in the cryptographic envelope and is encrypted under a public key. Whereas in Ref.2 the distributed data only contains an identifier of the encryption key. The encryption key is stored at a server and is retrieved upon the presentation of the key identifier. Therefore with Ref.2 it is necessary to maintain a key, database at the server necessitating a measure of trust between a buy server and a document server.
Pretty Good Privacy (PGP) is a public-key based system for sending secure e-mail. The body of the e-mail is encrypted using an IDEA algorithm (see, e.g., Ref. I) and the encryption key is encrypted using the public key of the intended recipient. Both the encrypted e-mail text and the encrypted encryption key are sent. The recipient uses his private key to recover the encryption key, which is then used to recover the plain text.
There is described a method for the creation, distribution, and sale of digital information using the methods and techniques of secure cryptographic envelopes. Cryptographic envelopes use modern cryptographic techniques (such as encryption and authentication) to secure document parts from unauthorized reading and tampering.
The process described in this disclosure allows parts of a cryptographic envelope to be bought by a user and their informational contents released in a secure and controlled manner. Additional processing of the parts are introduced to deter piracy. Furthermore, the use of public-key technology makes cryptographic envelope technique a convenient, secure, and self-contained, means of distributing digital information.
The basic model for information distribution assumed here is super distribution. (See Ref.5 for a more in-depth discussion on the subject). The basic idea is that digital documents (or parts) can be freely distribution over the Internet, by radio or television signals, by cable, by satellite, by local area networks, by diskettes, by CD-ROMs, and by BBS as long as each document is encrypted. Assuming that the encryption process is sufficiently secure, the only way a user can have access to the content is to purchase the necessary PEKs (part encryption keys) that are typically orders of magnitudes more compact than the documents they decrypt.
Super distribution is a powerful concept because it decouples the problem of information distribution into:
(1) the distribution of bulk data; and
(2) the controlled release of content through the release of PEKs.
According to one aspect of the of the invention there is provided a method of providing access to content data in a cryptographic envelope, said method comprising: a) transmitting a request from a client server, said request being a request to access a part of said cryptographic envelope said request comprising at least an encrypted part encryption key which is a public key encryption of a key used to encrypt said part; b) transmitting a response, in response to said request, from said server to said client, said response being a transformation of said encrypted part encryption key, said transformation being characterised by: decrypting said encrypted part encryption key using a secret key associated. with said public key, and encrypting, in the server, said part encryption key using a second public key; and decrypting, in the client, said transformed key using a second secret key associated with said second public key into said part encryption key, wherein said selected part is decrypted into clear text using said part encryption key, thereby providing access to said client.
According to a second aspect of the invention there is provided a method of creating a cryptographic envelope, which can be distributed arbitrarily to a plurality of users, said envelope being a digital document which is an aggregation of information parts, said method comprising: A) encrypting one of said information parts with a part encryption key to produce an encrypted part, which is included in said envelope; b) encrypting said part encryption key with a first public key to produce an encrypted part encryption key, which is included in said envelope, said first public key having a first secret key, c) creating a list of parts that are included in said envelope, each entry in said list comprising a part name and a secure hash of said named part, said list also being included in said envelope; and characterised by D) signing said list with a second secret key to produce a signature which is included in said envelope; wherein the integrity of said list can be checked using a second public key associated with said second secret key to verify said signature, and wherein the integrity of any one part of said envelope can be checked by computing a second secure hash of said one part and comparing said second hash with its corresponding hash in said list, and wherein the information content of said encrypted part is protected from disclosure and can only be recovered with said part encryption key, and wherein said part encryption key can be recovered by decryption of said encrypted part encryption key using the first secret key corresponding to said first public key.
Accordingly, a method of creating a cryptographic envelope is provided which can be distributed arbitrarily to any number of users, where only authorized users have access to the clear text content of the secure information parts. With this invention, each of the information parts is encrypted with a corresponding part encryption key to generate an encrypted information part. Each part encryption key is then encrypted with a public key. A list of parts that are included in the envelope is also created, and each entry in the list has a part name and a secure hash of the named part. The envelope, then, includes the encrypted information parts, the unencrypted information parts, the encrypted part encryption keys and the list of parts. Finally, the list of parts is signed with a secret key to produce a signature, and this signature is also included in the envelope. The integrity of the list can be checked using a second public key associated with the secret key that was used to sign the list. The integrity of any one information part can be checked by computing a second hash on the part and comparing the second hash with the corresponding hash for the part in the list. Finally the information content of the encrypted part is protected from disclosure and can only be recovered with a part encryption key, and knowledge of a secret corresponding to a public key is necessary to obtain an unencrypted part encryption key. The latter unencrypted key is then used to generate clear text from the information part.
FIG.1 gives an overview of the five steps of a cryptographic envelope process. The main entities involved in the process are the Document Server (DS) 100, the Buy Server (BS) 102, the decryption fingerprinting and watermarking module (DFWM) 103, and user personal computer (UPC) 101;
FIG. 2 shows the structure of a typical cryptographic envelope. The minimal elements are an encrypted part 203 and its associated encrypted part encryption key (PEK) 202, list of parts 209, and signature of list of parts 208;
FIG. 3 shows the structure of a bill of materials (BOM), which has a list of parts 209. Each entry of the table contains the part name 302, e.g., "Abstract", and the MessageDigest5 (MD5), that is, a secure hash, of the named part 301, e.g, "13ADBF77F...". The MD5 of the list is computed and the resultant hash is signed using the DS's secret key to produce a digital signature 208. The list 209 and the signature 208 form the BOM;
FIG. 4 shows a typical price matrix. The columns shows the discount factor for various membership categories (402, 403, 404, 405), and the rows show the quantity discount (406, 407, 408, 409). A sample formula for computing the price of the n-th copy and the total price of n copies is as shown 401;
FIG. 5 shows a Buy Request Message (BRM) 500. Included in the BRM are the encrypted PEKs (202, 211), encrypted fingerprinting and watermarking instructions 205, terms and conditions 206, and BOM 207. Items 202, 205, 206, 207, and 211 are copied from the cryptographic envelope 200 (see Figure 2). The other parts of the BRM (501-505) are generated at the UPC; and
FIG. 6 shows a Buy Server Response (BSR) 600. The Buy Server (BS)translates the PEKs to produce translated PEKs (602, 603) which only the DFWM 103 can decrypt. The fingerprinting and watermarking instructions are decrypted, customized, and re-encrypted, and the result 604 can be decrypted only by the DFWM. The terms and conditions in the BRM (500, Figure 5) are also evaluated and may produce updated or transformed terms and conditions 605. The actual purchase price 601 is computed by applying the appropriate discounts on the base price.
Referring to Figure 1, one of the key advantages of the cryptographic envelope process is security. It is assumed that the BS (Buy Server) 102 and the DS (Document Server) 100 are secure. E.g., they are managed and owned by the respective business partners in the enterprise and are operated by trusted personnel inside a glass house.
An overview of the processing steps is as follows. (See Figure 1.) Step 1 Cryptographic Envelope Creation Step 2 Cryptographic Envelope Distribution Step 3 User-Initiated Buy Request Step 4 Buy Server Response Step 5 Opening of Cryptographic Envelope
Each of these processing steps is described in greater detail.
A cryptographic envelope is a grouping of information parts. See 201 - 211 of FIG. 2. Some of the information parts are encrypted while others are in clear text. The cryptographic envelope process is compatible with a wide variety of grouping technologies (e.g. zip, tar, and the more object-oriented approaches of OpenDoc Bento and Microsoft OLE). The requirements on the grouping method is minimal:
(1) the parts can be aggregated into a unit suitable for distribution and the parts can later be individually retrieved; and
(2) there should be means of associating different parts, e.g., by naming, pointers, or indices.
Information parts are of two types: document (201 and 203) and control (202, 204 - 211). Document parts are the "contents". Some examples of document parts are abstracts, table of contents, figures, tables, and texts. They could also be portions of an executable program, a library of subroutines, software modules, or object components.
Referring to Figure 2, document parts may be encrypted (203). Encrypted document parts 203 are often the "valuable contents" to be purchased by the user (e.g., a section of a book, a high resolution JPEG picture, or an MPEG stream). Unencrypted parts are the "teasers" 201 (e.g., reviews of the book by others, the table of content, the abstract, or a low resolution JPEG picture). The purpose of the unencrypted parts is to allow the user to "preview", "sample", or "browse" the contents of a cryptographic envelope before the actual purchase.
Control parts are the metadata needed to support the functions and the process model of a cryptographic envelope. There are two main functions: authenticity and confidentiality. The functions of the cryptographic envelope are not tampered with. This authentication function is achieved by using digital signatures. The confidentiality function is achieved by encryption (e.g., using DES or IDEA). The basics of these encryption and authentication techniques are well known in the art and can be found in any modern text on cryptography (e.g, see Ref.1). All control parts are authenticated and some may be encrypted, if necessary.
Examples of control parts are price matrix (See Figure 4,400) and fingerprinting and watermarking instructions 205 for the post-processing of the document parts. The post-processing of the document parts is performed by the DFWM, when the cryptographic envelope is open. Fingerprinting and watermarking are examples of post-processing, they mark document parts in a way to deter piracy.
Referring to Figure 4. The price matrix 400 describes the pricing structure for the purchase of the document parts, e.g., volume discount for buying multiple copies, discount for club membership, or corporate discount. An example formula 401 to compute the purchase price of n copies of a document. (Note, the price discount factor may also be time dependent, in which case the columns of the price matix (402 - 405) are time-limited special offers instead of club membership).
Referring to Figure 2, terms and conditions 206 on the purchase and the use of the document parts can also be included in the cryptographic envelope. They may be included as document parts (in which case they will be made visible to the user) or included as control parts (in which case they will be evaluated at the Buy Server (BS) 102 and possibly again at the user's personal computer (UPC) 101). The document parts contain some textual information, and the control parts may contain some program (e.g., written in a scripting language such as Perl (Ref.4) implementing the terms and conditions. (Note: The fingerprinting and watermarking instructions, and the price matrix. We list them explicitly for clarity).
We now describe a method in which confidentiality can be achieved. Parts of value are encrypted using a DES (Data Encryption Standard) algorithm (e.g., see Ref.1). Different parts are encrypted using different PEKs (part encryption keys). These keys are chosen randomly and independently.
There are many ways of generating a random encryption key. One way is to use random or a pseudo-random number generator to produce a random string, which is used as the key. More details on these scheme can be found in [Refs.1 and 3)
Each PEK is encrypted using the public key of a BS (Buy Server) 102 and the resultant encrypted PEK 202 (Figure 2) becomes a control part in the cryptographic envelope. (Note: a PEK may be encrypted using different BS public keys and all theses encrypted PEKs included in the cryptographic envelope.)
There are many ways of ensuring the authenticity of a cryptographic envelope and its parts. We now describe one such method. Every cryptographic envelope has a special control part called BOM (Bill of Materials) 207. The BOM is consist of two parts:
(1) a list of parts 209; and
(2) a digital signature 208.
We apply a secure hash function, MessageDigestS (MD5) (see, e.g., Ref.1 for details), to each part included in a cryptographic envelope and create a list. Referring to Figure 3, each entry in the list contains the part name or reference 302 and a secure hash 301 of the information part corresponding to the part name. (E.g., In the case of a file-based grouping, list of parts would be a file containing the file names of all the files and their corresponding hash results).
The list is then digitally signed with a secret key known only to the DS (Document Server) 100. There are many ways of digitally signing a document (see, e.g., Ref.1). One way is to compute the MD5 (or any other secure hash) of the list of parts and to encrypt the resultant hash using the secret key (to produce a signature) 208. The list of parts and the signature together are referred to as the BOM 207. Note, that only the public key of the DS is needed to verify the authenticity of the BOM.
An important feature of cryptographic envelope is that it is self-contained in the following sense. Only the public key of a DS is needed to verify the authenticity of the cryptographic envelope. Because the encrypted PEKs (202, 210, 211, see Figure 2) are with the cryptographic envelope, only the secret key of a BS is needed recover the content. Moreover, different Document Servers can generate cryptographic envelopes using only the public key of the BS;
no other communications between BSs and DSs are needed
We now summarize the processing steps in the creation of acryptographic envelope. (See Figure 2)
Assemble information parts to be included in the cryptographic envelope.
Apply optional processing steps (e.g., compression, pre-fingerprinting, and pre-watermarking) to parts. Keep sufficient state information of these processing steps to undo the operations later.
Generate random PEKs (part encryption keys) 202, one for each part to be encrypted.
Encrypt document parts with their respective PEKs to form the encrypted parts (203, 204, 205), which are included in the cryptographic envelope.
The PEKs are then encrypted using the public key of a BS to form encrypted PEKs (202, 210, 211), which are included in the cryptographic envelope. Encrypted PEKs and their corresponding encrypted parts are associated.
Also encrypt the instructions and other state information from Step 1-b using some random PEKs. The PEKs are encrypted with a public key of the BS. Both encrypted parts (203, 204, 205) and encrypted PEKs (202, 210, 211) are placed in the cryptographic envelope.
Include in the cryptographic envelope clear text parts such as 'teasers', abstracts, and a table of content 201.
Include terms and conditions such as fingerprinting and watermarking instructions 205 and pricing matrix 206. Encrypt any parts or sub-parts if necessary (and include their encrypted PEKs). As before associate encrypted parts with their encrypted PEKs.
Create a list 209 of information parts, listing all the parts assembled and computing a secure hash for each of the parts listed.
Create a signature 208 for BOM 207 by digitally signing the list, e.g., computing the secure hash of the list and encrypting it with the DS secret key. The BOM 207 (list 209 and signature 208) are added to cryptographic envelope.
See Figure 2 for details on possible cryptographic envelope structure.
This step is often preceded by a user browsing the plain text 'teaser' 201 portion of a cryptographic envelope. A user who is interested in the cryptographic envelope content would have to buy the necessary PEKs from the BS. (See Figure 1.)
The browsing of the cryptographic envelope is performed with the help of a GUI such as a modified web browser that understands the cryptographic envelope structure. First, the modified browser must be able to check the integrity of the cryptographic envelope. The user is notified of any tampering of the cryptographic envelope parts through the integrity check. Next, the browser should be able to display the clear texts in the cryptographic envelope, e.g., display the abstracts and table of contents. Finally, referring to Figures 2 and 5, the browser must the able to extract the necessary parts from the cryptographic envelope 200 to construct a BRM (Buy Request Message) 500.
More specific to our methods is that we assume, as a result of registration, a secure DFWM (103, Figure 1) (decryption fingerprinting watermarking module) is instantiated at the UPC.
For more information on fingerprinting and watermarking techniques, see application serial number 08/494,615 filed on June 23, 1995, and assigned to the same assignee of the instant application.
There are various implementations of a secure DFWM. The simpliest is based on the public key techniques, where the DFWM securely generates and stores a secret key within the DFWM security boundary. For example, the DFWM could use a pseudo-random number generator to create a public-secret key pair. The DFWM secret key is stored within the DFWM and the public key is known to the outside. The registration process allows the trusted third party to certify the DFWM public key. (See e.g., Ref.1 on public key certification process). The DFWM secret key is the only secret information kept in the DFWM module.
Through the Graphical User Interface (GUI), the user is prompted with a list of articles contained in the cryptographic envelope. The user may browse the relevant abstracts for more information. The user may also know the list price of the articles. If the user still wants to buy the articles, the user would initiate a buy-request through the GUI, resulting in a BRM (Buy Request Message) (see 500, Figure 5) being sent to the BS 102.
Before the buy request can be completed, the system may want to authenticate the user. There are many well known techniques for user authentication by the system. E.g., one such technique (similar to what is used in Pretty Good Privacy Ref.3) is to store the user private key encrypted on the disk drive of the UPC.
Referring to Figure 5, the BRM 500 contains the following information copied or extracted from the cryptographic envelope (200, Figure 2):
BOM of the cryptographic envelope 207
List of articles to buy 501
PEKs associated with the list of articles and other control parts (202 and 211)
Terms and conditions (such as price matrix, etc.) 206; and the following information copied or extracted from the user environment, from the DFWM, or by the user:
List of user credentials (e.g., membership and discount cards) and user authentication related information 502;
Environmental variables (e.g., date and time, locale, DFWM or machine hardware ID) 503;
The DFWM public key 504.
Standard cryptographic techniques, such as encryption and authentication, may be applied to the BRM. One way of authenticating the BRM is to compute the MD5 of the entire BRM, and using the secret key of the DFWM, encrypt the resultant MD5 to produce a signature 505, which is added t the end of the BRM.
We now summarize the steps leading to the generation of a BRM:
Perusal of the clear text portions of the cryptographic envelope through GUI;
Selection of information parts of cryptographic envelope to be purchased;
Explicit agreement by the user to the terms and conditions 206 of the purchase (e.g., list price, promise not to redistribute);
Prompting the user to enter a password for authentication. (As a result some user authentication related information is generated and included in the BRM);
Generation of BRM 500 by the GUI; and
Sending BRM to BS.
Note: a BRM can be viewed as a special type of cryptographic envelopenamely a "Buy Request" cryptographic envelope. Step 4: Buy Server Response
Referring to Figure 6, we now summarize the steps taken by the BS, from receiving a BRM to sending a BSR.
Receiving a BRM.
Check the authenticity of BRM (by checking BOM), verify user credentials, verify user authentication related information, verify DFWM public key, check environmental variables.
Evaluate terms and conditions, using as inputs (from BRM) the user credentials, the price matrix, and environmental variables and (from BS) user information in database and additional environmental variables. The outputs from the evaluation of the terms and conditions are:
(a) whether the user is allowed access to the parts; and
(b) the actual price for purchasing the parts 601.
Check if user is allowed access and the user has sufficient credit. If not, abort and send an error BSR.
Translate PEKs. (Decrypt PEKs using BS private key and reencrypt PEKs using DFWM public key.) Include them in BSR (602, 603).
Customize fingerprinting and watermarking instructions. (Decrypt instructions, include user specific and transaction-related information in instructions. Encrypt modified instructions using DFWM public key). Include them in BSR 604.
Include transformed terms and conditions and other restrictions on the use of the documents in BSR 605.
Send BSR to user.
A BSR can be viewed as a special type of cryptographic envelope --- namely a "License Cryptographic Envelope". Again standard cryptographic techniques such as encryption and authentication can be applied to protect the privacy and authenticity of a BSR 606. (See e.g., Ref.1)
The BSR is the "key" to unlock the cryptographic envelope. The content of the BSR is usable only to the specific DFWM since the PEKs are all encrypted under the DFWM public key. Referring to Figure 6, the steps involved in the opening of a cryptographic envelope are as follows.
The DFWM checks to ensure the authenticity of the BSR 606. The opening continues only if the BSR authentication is successful.
The user may optionally be prompted with the updated licensing terms and conditions 605 in the BSR. The opening continues only if the user agrees to the terms and conditions.
The DFWM authenticates and decrypts the translated PEKs (602, 603) and the customized fingerprinting and watermarking instructions (604). The opening continues only if the authentication is successful.
Using the decrypted PEKs, the DFWM decrypts the corresponding encrypted parts of the cryptographic envelope (203, 205).
The DFWM applies the appropriate watermarking and fingerprinting instructions 604 to the decrypted documents. (The fingerprinting and watermarking are customized to the user, providing additional deterrence against unauthorized distribution).
The resultant decrypted documents are released to the user, outside of the DFWM security boundary.
In summary there is described a method and apparatus to create, distribute, sell and control access to digital documents using secure cryptographic envelopes. An envelope is an aggregation of information parts, where each of the parts to be protected are encrypted with a corresponding part encryption key. These encrypted information parts along with the other information parts become part of the envelope. Each part encryption key is also encrypted with a public key, and these encrypted part encryption keys are also included in the envelope. The envelope also includes a list of parts where each entry in the list has a part name and a secure hash of the named part. The list is then signed with a secret key to generate a signature, which is also included in the envelope. The signature can be verified using a second public key associated with first secret key, and the integrity of any information part in the envelope can be checked by computing a second hash and comparing it with the corresponding hash in the list of parts. Also, the information content of any encrypted part can only be recovered by knowledge of a second secret key corresponding to the public key that was used to encrypt the part encryption keys.
2. IBM CD-Showcase Patent (US PATENT Number 5,319,705. Issued to B. Halter et al on June 7. 1994).
3. S. Garfinkel, Pretty Good Privacy, O'Reilly & Associates, 10 Inc.,1994.
4. L.W. Wall and R.L. Schwartz, Programming Perl, O'Reilly & W Associates, Inc., 1991.
5. B. Cox, Superdistribution and Electronic Objects, Dr. Dobb's Journal, Vol. 17, No. 10. Oct. 1992.
6. US Patent Application, serial number 08/494,615, A METHOD TO PETER DOCUMENT AND INTELLECTUAL PROPERTY PRIVACY THROUGH INDIVIDUALIZATION, filed June 23, 1995, and assigned to the assignee of the instant application.
A method of providing access to content data in a cryptographic envelope, said method comprising:
a) transmitting a request from a client (101) server (100), said request being a request to access a part (203) of said cryptographic envelope (200) said request comprising at least an encrypted part encryption key (202) which is a public key encryption of a key used to encrypt said part;
b) transmitting a response, in response to said request, from said server (102) to said client (101), said response being a transformation of said encrypted part encryption key (202), said transformation being characterised by:
decrypting said encrypted part encryption key (202) using a secret key associated with said public key, and
encrypting, in the server (102), said part encryption key using a second public key; and
decrypting, in the client (101), said transformed key using a second secret key associated with said second public key into said part encryption key, wherein said selected part is decrypted into clear text using said part encryption key, thereby providing access to said client (101).
A method of creating a cryptographic envelope (200), which can be distributed arbitrarily to a plurality of users, said envelope being a digital document which is an aggregation of information parts, said method comprising:
a) encrypting one of said information parts (203) with a part encryption key to produce an encrypted part, which is included in said envelope;
b) encrypting said part encryption key with a first public key to produce an encrypted part encryption key (202), which is included in said envelope, said first public key having a first secret key,
c) creating a list of parts (209) that are included in said envelope (200), each entry in said list comprising a part name and a secure hash of said named part, said list also being included in said envelope (200); and characterised by
d) signing said list (209) with a second secret key to produce a signature (209) which is included in said envelope (200);
wherein the integrity of said list (209) can be checked using a second public key associated with said second secret key to verify said signature, and wherein the integrity of any one part of said envelope (200) can be checked by computing a second secure hash of said one part and comparing said second hash with its corresponding hash in said list, and wherein the information content of said encrypted part is protected from disclosure and can only be recovered with said part encryption key, and wherein said part encryption key can be recovered by decryption of said encrypted part encryption key using the first secret key corresponding to said first public key.
A method as recited in claim 2, further comprising the step of modifying selected ones of said parts of said document by insertions, deletions or changes of selected words or bits in said selected parts and maintaining state information associating each modified document part with its modifications to recover a respective uzunodified document -
A method as recited in claim 3, wherein said modifications are applied to said selected ones of said parts before said encryption of said part, wherein said state information is encrypted using a third part encryption key (211) which is encrypted with a third public key.
A method as recited in claims 2, 3 or 4, wherein said cryptographic envelope (200) contains a computer program, which is to be executed at a server and the result of said execution determines subsequent operations by said server.
A method as recited in claim 5, wherein said program describes the terms and conditions on the access of said information parts in said cryptographic envelope (200), and wherein said execution determines whether access to said information parts is granted.
A method as recited in claim 5, wherein said program comprises instructions to modify each document part. wherein each part is modified by insertions, deletions, or changes of selected words or bits in each part, and wherein state information associating each modified document part with its modifications is maintained to recover a respective unmodified document.
EP19970301307 1996-03-29 1997-02-27 Creation and distribution of digital documents Expired - Lifetime EP0798892B1 (en)
US625475 1996-03-29
EP0798892A2 EP0798892A2 (en) 1997-10-01
EP0798892A3 EP0798892A3 (en) 2000-04-26
EP0798892B1 true EP0798892B1 (en) 2006-07-12
EP19970301307 Expired - Lifetime EP0798892B1 (en) 1996-03-29 1997-02-27 Creation and distribution of digital documents
MXPA00005358A (en) * 1998-10-08 2004-12-02 Matsushita Electric Ind Co Ltd Device and method for recording, reproducing and processing data.
WO2000051286A1 (en) 1999-02-26 2000-08-31 Bitwise Designs, Inc. Digital file management and imaging system and method including secure file marking
GB2350529B (en) 1999-05-22 2004-03-10 Ibm Electronic contracts
WO2001050319A2 (en) * 1999-12-30 2001-07-12 Macrovision Corporation System and method for providing electronic licenses
KR100653804B1 (en) * 2000-01-21 2006-12-05 소니 가부시끼 가이샤 Data processing apparatus and method thereof
JP4660899B2 (en) * 2000-07-24 2011-03-30 ソニー株式会社 Data processing apparatus, data processing method, and program providing medium
JP2005519364A (en) * 2002-02-27 2005-06-30 コンテントガード ホールディングズ インコーポレイテッドＣｏｎｔｅｎｔＧｕａｒｄ Ｈｏｌｄｉｎｇｓ， Ｉｎｃ． System and method for licensing a network service, and, exercise system and computer-implemented method
AU2002233609B2 (en) * 2001-03-28 2008-05-29 Nds Limited Digital rights management system and method
AU2002350203A1 (en) 2001-11-20 2003-06-10 Contentguard Holdings, Inc. Systems and methods for creating, manipulating and processing rights and contract expressions using tokenized templates
CN1653462A (en) 2002-03-14 2005-08-10 康坦夹德控股股份有限公司 Rights expression profile system and method using templates and profiles
AU2003218489A1 (en) * 2002-04-02 2003-10-20 James Chladek System and method for subscription broadcast medium delivered over a broadband network
WO2003094077A1 (en) 2002-04-29 2003-11-13 Contentguard Holdings, Inc. System and method for specifying and processing legality expressions
WO2004032411A1 (en) 2002-09-11 2004-04-15 Giesecke & Devrient Gmbh Protected cryptographic calculation
EP1927060B1 (en) * 2005-08-09 2019-10-09 Nexsan Technologies Canada Inc. Data archiving method and system
WO2009111408A1 (en) 2008-03-04 2009-09-11 Apple Inc. System and method of authorizing execution of software code based on at least one installed profile
CN101981866B (en) * 2008-04-07 2014-08-27 汤姆森许可贸易公司 Method for preventing laundering and repackaging of multimedia content in content distribution systems
EP0689697A1 (en) * 1992-09-21 1996-01-03 Uniloc (Singapore) Private Limited System for software registration
JP3130267B2 (en) 2001-01-31
Free format text: 7H 04L 9/32 A, 7G 07F 7/10 B
Ipc: H04L 9/32 20060101AFI20051221BHEP
Ipc: G07F 7/10 20060101ALI20051221BHEP
Ipc: H04L 9/08 20060101ALI20051221BHEP
Ref document number: 69736310