Secure document management system

[0001] The invention relates to a secure document management system for storing, retrieving and updating data or documents stored in a database system where access to the data is restricted from the database administrator.

[0002] Database management systems are very efficient at storing large amounts of data; however, the data on these systems can be open to compromise or corruption by the database storage administrator or others gaining access to the system, either by accident or otherwise.

[0003] In this discussion of the background of the invention, and in the description of the invention that follows in later sections of this description reference will be made to a number of drawings of which the following is:

[0012] It has been desirable to develop a system for management of application access control information where the access to a data element in storage in the database system cannot be compromised by the actions of the database storage administrator, and where no persistent storage is required on the application server in order to maintain trust in integrity of the data, and in enforcement of access control to the data.

[0013] A common implementation of a computing service relies on the availability of two entities: an Application Server, which is responsible for executing application logic of an application being used; and a Database Server, which is responsible for persistent storage of data. FIG. 1 illustrates one version of such a system with two application servers 1, 2, and a database server 3.

[0014] FIG. 2 illustrates a slightly more complex data processing environment such as found in network computing using a 3 tier architecture using a browser client 8, which may be employed by a user to gain access to store, update or retrieve data, through an Information Processing network 6, to application web server 4 to access database server 3 which can access the data.

[0015] Frequently one of the responsibilities of the application server is to enforce access control to the data or the services that it manages. This is commonly accomplished by the use of Access Control Lists (ACLs). An access control list (ACL) is associated with the secure item (the protected data), and contains the list of authorized entities (e.g. people, organizations, or applications), as well as each entity's permission for access to the item. It is very convenient to store the access control list on the database server, so that application data, as well as the corresponding access control information are managed by the same database store.

[0016] One of the aspects of this invention addresses the area of trust between an application server and a database server to which it has access. In prior art known systems the end users of a data processing system trust both the application server and the database server to have access to their data.

[0017] However, where multiple applications may access a database server, a user may only trust the application that the user is accessing rather than any other application that uses the same database server. In these situations it is important to ensure that the following objectives are met:

• [0018] 1. The database server administrator cannot understand the information that it stores;
• [0019] 2. The database server administrator cannot modify the information that it stores; and,
• [0020] 3. The database server administrator cannot modify the access permissions to the information that it stores.

[0021] The present invention describes a system to satisfy the above requirements so that even a multi-tier system can use a database server for persistent data management, without requiring the database store to be trusted with the contents of the data nor access to the data.

[0022] One aspect of the invention provides apparatus for secure management of data in a computer controlled storage system including: a trusted data management server (tdm server), responsive to a user or user program application, for storing data in and retrieving data from a storage system including: a security structure generator to generate the following security management structures: an unique identifier for the data; access control information for the data; a data signature for authenticating the data from the data and the unique identifier; and an access control information signature for authenticating the access control information from the access control information and the unique identifier.

[0023] Preferably the apparatus would include an encryption device or program for encrypting the data before storing it, and, if required by the tdm server for added security, the access control information, as well.

[0024] The tdm server can control access for the data stored in the storage with the unique identifier.

[0025] The access control of the tdm server is responsive to a request from a user for accessing secured data from the storage system, and to:

• • [0026] retrieve a unique identifier for the secured data from the user or storage system;
  • [0027] retrieve from the storage system the security management structures corresponding to the secured data; and
    carry out the following determination steps:
  • [0028] determine if the access control information and unique identifier correspond with the access control information signature;
  • [0029] determine if the secured data and its unique identifier correspond with the data signature;
  • [0030] determine if the unique identifier of the access control information corresponds with the unique identifier of the secured data; and
  • [0031] determine whether the access control information permits the user to access the secured data; and then grant access to the user to the data if each of the determination steps is satisfied, and otherwise refuse access.

[0032] The access control may further notify the user if access is refused.

[0033] Another aspect of the system of the invention for secure management of data in a computer controlled storage system includes:

• • [0034] a trusted data management server (tdm server) accessible to a user or user program application;
  • [0035] storage managed by a storage server;
  • [0036] a communication system for connecting the trusted data management server and the storage server for the transfer of information therebetween; the tdm server being adapted to manage protected data in the storage means with unique identifiers, data signatures, access control information, and access control information signatures;
  • [0037] the storage server being adapted to store protected data, signatures of the data, unique identifiers, access information, access information signatures, to permit access of the protected data under management of the tdm server.

[0038] Another aspect of the invention provides a system for the secure management of documents in a database system including:

• • [0039] a trusted document management server (tdm server) accessible to a user or user program application;
  • [0040] database storage managed by a database server (db server);
  • [0041] a communication system for communicating between the trusted document management server and the database server;
  • [0042] wherein the tdm server is adapted to handle requests for managing protected documents in the database with unique identifiers and access control information; and
  • [0043] wherein the db server is adapted to store protected documents, signatures of the documents, unique identifiers and access information, signature of the access information, to permit access of the protected documents under management of the tdm server.

[0044] In yet another aspect of the invention, on the request of a user to create and store a protected

• • [0045] document in the database,
  • [0046] the tdm server is adapted:
  • [0047] to generate one or more random identifiers and request that the db server reserve one of the random identifiers as a unique identifier for the document;
  • [0048] to compute a signature of the document which authenticates a predetermined set of attributes including document content, and the unique identifier for the document;
  • [0049] to create access control information in the form of an access control list;
  • [0050] to compute a signature of the access control list which authenticates a predetermined set of attributes including the access control information content, and the unique identifier for the document; and,
  • [0051] to have the database server store in the database, the document in protected form, its signature, the access control list and the signature of the access control list; and
  • [0052] wherein the database server is adapted to verify whether the random identifier does not correspond to a unique access number of any other protected document, and if so, to reserve it.

[0053] Another aspect of the invention provides a method for secure management of data in a computer controlled storage system including:

• • [0054] in a trusted data management server (tdm server), responsive to a user or user program application, for storing data in and retrieving data from a storage system generating the following security management structures:
  • [0055] a unique identifier for the data;
  • [0056] access control information for the data;
  • [0057] a data signature for authenticating the data from the data and the unique identifier; and
  • [0058] an access control information signature for authenticating the access control information from the access control information and the unique identifier.

[0059] For added security the tdm server preferably can encrypt the data and the access control information before storing them in the storage.

[0060] In yet another aspect of the method of the invention, responsive to a request from a user for accessing secured data from the storage system, the tdm server:

• • [0061] retrieves a unique identifier for the secured data from the user or database storage;
  • [0062] retrieves from the storage system the security management structures corresponding to the secured data; and
  • [0063] carries out the following determination steps:
  • [0064] determine if the access control information and its unique identifier correspond with the access control information signature;
  • [0065] determine if the secured data and its unique identifier correspond with the data signature;
  • [0066] determine if the unique identifier of the access control information corresponds with the secured data; and
  • [0067] determine whether the access control information permits the user to access the secured data;
  • [0068] and then grants access to the user to the data if each of the determination steps is satisfied, and otherwise refusing access.

[0069] In still another aspect of the invention provides, in a system for secure management of data in a computer controlled storage system:

• • [0070] a trusted data management server (tdm server) accessible to a user or user program application;
  • [0071] storage managed by a storage server;
  • [0072] a communication system for connecting the trusted data management server and the storage server for the transfer of information therebetween;
  • [0073] using tdm server to manage protected data in the storage means with unique identifiers, data signatures, access control information, and access control information signatures;
  • [0074] and stores in storage protected data, signatures of the data, unique identifiers, access information, access information signatures, to permit access of the protected data under management of the tdm server.

[0075] In still another aspect of the invention provides, in a system for the secure management of documents in a database system:

• • [0076] a trusted document management server (tdm server) accessible to a user or user program application;
  • [0077] database storage managed by a database server (db server); a communication system for communicating between the trusted document management server and the database server;
  • [0078] using the tdm server to handle requests for managing protected documents in the database by using unique identifiers and access control information; and
  • [0079] storing in the database storage protected documents, signatures of the documents, unique identifiers and access information, signature of the access information, to permit access of the protected documents under management of the tdm server. On the request of a user to create and store a protected document in the database, the tdm server generates one or more random numbers and request that the db server reserves one of the random numbers as a document access key;
  • [0080] computes a signature of the document which authenticates a predetermined set of attributes including document content, and the document key;
  • [0081] creates access control information in the form of an access control list;
  • [0082] computes a signature of the access control list which authenticates a predetermined set of attributes including the access control information content, and the document key; and, has the database server store in the database, the document in protected form, its signature, the access control list and the signature of the access control list.

[0083] The invention also provides software embodiments such as media encoded with program code to effect the above described systems or programs.

[0084] The present invention satisfies the three numbered requirements listed above for reducing the requirement for trust in a database server, so that protected data stored on a database can be stored without requiring persistent storage on the application server. The invention has a number of features useful in real data processing systems. Protected data (or documents) and access control information (an ACL for instance) are stored separately, but may be managed by the same database storage administrator. A protected document need not be re-signed if the ACL changes, and vice versa; the ACL need not be re-signed if the document changes. In addition the present invention provides data and ACL integrity verification by a relatively inexpensive process.

[0085] The problem of reducing trust in a database is summarized in the above three numbered objectives. The first and second objectives, that the database server administrator cannot understand the information it stores, or to modify the access permissions to the document it stores, can be achieved by the use of encryption and digital signatures by the application server, as follows:

[0086] The application server signs all data elements with its private key. In this way a rogue database administrator cannot modify the data element. The digital signature may be stored in the database, together with the data.

[0087] The application server encrypts each data element, so that the data can only be decrypted with the application server's private key. Cryptographic keys are discussed below.

[0088] In a preferred design of the secure document repository, we utilize the both symmetric and public-key asymmetric cryptography technology.

[0089] With public key cryptography, an application has two keys, referred to as a key pair. The public key is made available to all users, usually through a directory service, such as X.500 distributed directory. Public key distribution is not discussed in this disclosure. The private key is held locally by the application.

[0090] A data element encrypted with the public key may only be decrypted with the corresponding private key. Similarly, a data element encrypted with the private key may only be decrypted with the public key.

[0091] With symmetric key technology, a single key is used for both encryption and decryption. One advantage of symmetric key cryptography is that the encryption/decryption, and key generation are much faster than with public-key asymmetric technology.

[0092] Note that the plain-text data elements are signed by the application server, not the encrypted data elements. This also means that in order to verify a data element's signature, the data element must first be decrypted.

[0093] Private key storage on the application server is not addressed by this invention, as it is addressed by most modern cryptographic systems, which use a variety of techniques including protected files, specialized cryptographic coprocessors, or smart cards.

[0094] In a similar fashion, the application server can digitally sign the data element's access control list and store the signature together with the access control list in the application database If the ACL's signature corresponds to the actual ACL, it proves that this ACL was generated by the application server. To prevent the DB administrator from knowing even the contents of an ACL, the Application Server can optionally encrypt the ACL before storing it in the database, and decrypt the ACL after retrieving it from the database.

[0095] However, a simple digital signature is not enough to protect the ACL from attacks by the database administrator. For example, the database server could present to the application an ACL (correctly signed by the application server), which corresponds to a different data item. The following tables illustrate such an attack:

[0096]

Data element table
	data item key	data item content
	i1	data item 1
	i2	data item 2
Access Control table
	data item key	Access Control Info
	i1	ACL1
	12	ACL2

[0097] Let's say the application server requests the data item i1, and the corresponding access control information. The database administrator can move ACL2 into the row(s) that should be occupied by ACL1; hence the database server would return the contents i1, and with it ACL2. Thus, the application server is misled into thinking that ACL2 in fact controls access to item i1.

[0098] This technique can be used by a user who has access to item i2 (i.e. he is given permission in ACL2), but not to i1. The user could bribe the database administrator, so the two of them perform the above replay attack.

[0099] We propose to solve this problem by a special use of unique identifiers and digital signatures.

[0100] Each data item is associated with a unique identifier. This can be either the primary key of the database table, or a new field used exclusively to assure data security. The ACL table also contains the unique identifier, so that each individual ACL is associated with the same identifier that the corresponding data element is associated with. The application server can use digital signatures to ‘tie’ the data item to its access control list.

[0101] The data item signature must contain at least the following authenticated attributes:

• • [0102] data item contents
  • [0103] data item key

[0104] The ACL signature must contain at least the following authenticated attributes:

• • [0105] Serialized ACL
  • [0106] data item key

[0107] Thus, the database administrator cannot deceive the application server by moving rows in the database table.

Key Generation

[0108] One important aspect of the security of the above scheme is key generation. It is very important that the database server is unable to influence key the next key generated for an item. Otherwise, the system would be vulnerable to following attack:

[0109] Let's say a rogue user R wants to gain information to an item that user A will be creating. If user R is in collusion with the database administrator, they could do the following:

• • [0110] A user tries to create an item
  • [0111] The application server requests a new key
  • [0112] Rather than generating a new key, the database assigns the key of an existing item, whose ACL permits access to the item to user R. —The application server sends a request to the database to create a new signed and encrypted item with the assigned key. The request includes the new signed ACL.
  • [0113] The database administrator replaces the new signed ACL with the signed ACL of the item whose key he assigned to the new item.
  • [0114] The rogue user R now has access to the newly created item.

[0115] To prevent the above attack, it is important that the ‘key’ which is shared between the item and the ACL is not assigned by the database. Instead, it must be generated by the application server.

[0116] Since the application server should not require any local persistent storage, the only way to generate a key is by using a random generator. This way, the key generation would follow this process:

• • [0117] Application server generates a new random key.
  • [0118] Application server asks the database to reserve this random key.
  • [0119] The database server checks that the key is not used, and if so reserves it
  • [0120] The application server can now create the new item.

[0121] If the key is already used, the application server can try the process again. Note that if the application server should keep track of the number of consecutive duplicate keys—if the number is too large (e.g. 5 or 10), it indicates a potential attempt by the database server to ‘wait’ for a particular key.

[0122] Notice that in this process the random key may not need to be cryptographically random, i.e. an attack is impossible even if the database server is able to predict the value of the next generated key. Given that the key space is large enough, the likelihood of a new random key being the same as that of an item whose ACL the user wants to assign to the new item, is minimal.

Creation and Storage of a Protected Document

[0123] Referring to FIG. 3, which depicts one embodiment of the invention, an application, in this case trusted document management server 10 is used to store and access protected data through database management server 3 which stores data such as a document in protected form, storing document access information 12, and the contents of the document 14 in database storage 16.

[0124] Referring to FIG. 4, which depicts the creation and storage of a protected document in accordance with one aspect of the invention, it may be seen that the process begins when a requester submits a document for protected storage under the invention 18, the trusted document management server generates a random number 20, and requests the database server to reserve the generated number as a key (i.e. a unique identifier; any unique identifier can be used as a key) for the document 22. If the database was unable to reserve the number as a key because it was already used for a document, then random number key generation process 20, 22 would be begun again. If the key was successfully reserved then the document is brought 26 into the trusted document management server's 10 local workspace (memory, disk, etc. not shown in FIG. 3). The trusted document management server 10 then computes 28, a digital signature of the document which authenticates at least the following attributes: document content, and document key (generated above), and optionally any other attributes the application requires, e.g. A time stamp. It then creates an initial access control list (ACL) 30. The server then computes a digital signature of the ACL 32, which authenticates at least the following attributes: the ACL content, and the document key and any other attributes, such as a time stamp that the application may require. The server then encrypts 33 the document and the ACL and instructs that database management system to store the document, its digital signature, the ACL, and the ACL's signature in the database 34. The database performs this storage operation 36, and optionally returns the key identification to the requester if required 38. This completes the storage 4 of a protected document in accordance with one aspect of the invention.

[0125] It should be noted that an ACL may contain a list of principals and for each principal there is associated a set of permissions to access document. These permissions typically pertain to whether a principal is allowed document access such as retrieve, update, erase, or append privileges.

Updating a Protected Document

[0126] Referring to FIG. 5, the process used by one aspect of the invention to update a document is depicted.

[0127] When a requester submits a new version of a previously stored document 42, for instance, to update the stored document, the trusted document management server obtains the key of the document which is to be updated 44, either from local information, such as from the requester 46, or from the database 48. It then perfumes an ACL check process to determine if the requester has the permission to update the document 50 (see FIG. 8 for details). If the requester does not have permission, it optionally can return a negative response to the requester 56. If the requester, on the other hand, does have permission, then the server computes a digital signature of the revised document, which authenticates at least the following attributes: document content, and document key, among others 52. It instructs the database management system to store the new document and its signature in the database 54, which it does 58.

Retrieving a Protected Document

[0128] FIG. 6 depicts the retrieval of a protected document from storage in accordance with one aspect of the invention.

[0129] For instance, a requester submits a request for retrieval of a document on behalf of a principal 62. The trusted document management server obtains the key 64 of the document, of which the ACL needs to be checked, either from the requester or from the database being accessed. It retrieves the ACL of the document and the signature of the ACL 66. It verifies whether the ACL corresponds to its signature 68. If the ACL does not correspond to the signature, the database integrity has apparently been violated as the ACL or document may not be authentic, retrieval will be rejected 72. If it verifies that the ACL corresponds to the ACL signature it retrieves 70 the protected document as well as the document's signature from the database. It verifies 74 that the document corresponds to its signature. If it does not, then database integrity has been violated, 72. If it authenticates that the document key signed by the document's signature does correspond to the key signed by the ACL signature 76 then it will proceed to use the ACL to determine 78 the principal's access to the document e.g. by determining if the principal is authorized to retrieve the document 80, in which case the document will be returned to the requester 82, or if not then a negative response may be returned to the requester 84.

Updating the ACL

[0130] Referring to FIG. 7 a process for updating the access control list (ACL) in accordance with one aspect of the invention is shown.

[0131] When a requester submits a new ACL to update the currently stored ACL 90, the trusted document server obtains the key of the document for which the ACL needs updating 92, either from the requester 94, or by retrieving it from the database 96. The server performs an ACL check 98 (the details of which may be seen in FIG. 8) to determine whether the requester has permission to update the ACL of the document. If so, the server computes 100 a digital signature of the new ACL, which authenticates at least the following attributes: ACL content, and the document key. The server then instructs the database management system to store the new ACL, and its signature in the database 102, which it does 104.

Checking an ACL

[0132] In order to perform the checking of an ACL (such as to determine a principal's access permission for a document one aspect of the invention provides the following method carried out by the trusted document server: the key of the document the ACL of which needs to be checked is obtained 106 either from the requester or from the database. The server retrieves the document's ACL and the signature of the ACL from the database 108. It checks to determine if the ACL corresponds to its signature 110; if not it has determined that the database integrity has been violated, as the document or the ACL may not be authentic 120. If the ACL corresponds to its signature the document protected by the ACL as well as the document's signature are retrieved from the database management system 112. The document is checked to determine if it corresponds to its signature 114. If not there has been an integrity violation of the database. If the document and its signature correspond the server determines if the document key signed by the document's signature corresponds to the key signed by the ACL's signature 116. If so it has authenticated the ACL. The ACL can then be used to determine document access 118 as desired.

[0133] The above noted processes of different aspects of the invention are represented by a simplified version of pseudo code which may be translated into a suitable computer control language to carry out the steps indicated. As any programmer skilled in the art of secure database access and management would be knowledgeable in the use of random number generation, keys, digital signatures and authentication procedures these have not been dealt with in detail.

[0134] New Document Creation

[0135] When the application server is creating a document, it needs to follow the following steps:

• • [0136] Generate a random number
  • [0137] Request the database server to reserve the random number as the new key
  • [0138] Compute a digital signature of the document, that includes as authenticated attributes the document itself, the new key, and any other attributes the application requires (e.g. time stamp).
  • [0139] Create a (default) ACL
  • [0140] Compute a digital signature of the ACL, that includes as authenticated attributes the ACL content, the new key, and any other attributes the application requires (e.g. time stamp).
  • [0141] Store the document, its signature, the ACL, and its signature, in the database server.

[0142] Document Retrieval

[0143] When the application server is retrieving a document on behalf of a particular user, it needs to follow the following steps:

• • [0144] Retrieve the ACL and it signature, which correspond to the supplied key
  • [0145] Verify the signature of the ACL—this makes sure that the ACL corresponds to the given key
  • [0146] If the signature is correct, check the user permission in the ACL—verify that the requester has as access to the document
  • [0147] If the user has permission, retrieve the document and its signature
  • [0148] If the document is encrypted, decrypt it
  • [0149] Verify the signature of the document—this makes sure that the document corresponds to the given key
  • [0150] If the signature is correct, the document has been successfully retrieved

[0151] ACL Update

[0152] When the application server is updating a ACL, it needs to follow the following steps:

[0153] Check that the requester has the right to update the ACL for this document

• • [0154] Compute a digital signature of the ACL, that includes as authenticated attributes the ACL
  • [0155] content, the document's key, and any other attributes the application requires (e.g. time stamp).
  • [0156] Store the ACL and its signature in the database server.

[0157] Document Update

[0158] When the application server is updating a document, it needs to follow the following steps:

• • [0159] Check that the requester has the right to update this document
  • [0160] Compute a digital signature of the document, that includes as authenticated attributes the document itself, the new key, and any other attributes the application requires (e.g. time stamp).
  • [0161] Store the document and its signature in the database server.

[0162] Add-Only Policy

[0163] It is important to note that the application server should enforce a policy where access to a document for a particular entity (e.g. user, group, role, etc.) may only be granted, but not removed.

[0164] If access to a document were to be removed, the database administrator could perform a replay attack, where he would restore the old ACL and signature, which granted access to the user. Note that the only possible result of this attack would be to re-authorize the entity to a document that it had been authorized to before, but the access was removed. There is still no way for the database administrator to grant access to a entity that had never been listed in this ACL before.

[0165] The only way to preserve the trust model for situations where the applications needs to remove a document from the database is to keep some kind of the database or ACL integrity tokens with the application server, which the application server would regularly verify, to ensure that the database had not been tampered with. However, this would ruin our requirement of no persistent storage on the application server.

[0166] Similarly, if a document were to be deleted from the database, the database administrator may attempt a replay attack by restoring it, as well as the corresponding signed ACL, from a backup. These situations are treated as being beyond the scope of this invention. We think that nevertheless, this invention is useful for a wide range of real-life applications. This is especially true if, while limited replay attacks were possible when document access is removed, the application server could still discover that such attacks had taken place, by looking in a transaction log.

[0167] For this reason, we recommend that an implementation of this system which does not enforce the add-only policy, should have two separate databases, administered by different people: an application database for storing documents, ACLs and signatures; and, a log database, for storing transaction logs.

[0168] Some databases provide built-in encryption of data, so that an intruder into the system on which the database resides cannot gain access to the data. The present invention goes beyond that—the database administrator himself cannot gain access to the data.

[0169] An alternative way of making sure that the database administrator cannot use a different ACL for the given document would involve including the document's cryptographic digest (e.g. MD5) as an authenticated attribute in the ACL signature.

[0170] The problem with this approach is that in order to verify ACL signature the application server would need to retrieve the document first and compute its digest. This is a computationally intensive process for large documents. With our approach the application server need not know the document content in order to verify its ACL, and therefore secure ACL search is much cheaper.

[0171] The present invention has the following advantages:

• • [0172] Achieves a higher level of trust in the application, by reducing the trust necessary for the database;
  • [0173] Access control information need not be re-signed if the document has changed;
  • [0174] Document need not be re-signed if the access control information has changed;
  • [0175] Does not require complex tools;
  • [0176] No cryptographic functions on the database server;
  • [0177] Access control information need not be encrypted; hence bulk search can be done by database operations;
  • [0178] No persistent storage required on the application server;
  • [0179] Existing n-tier systems can be migrated to the proposed architecture to increase their trust level.

[0180] The present invention can be realized in hardware, software, or a combination of hardware and software. The present invention can be realized in a centralized fashion in one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system—or other apparatus adapted for carrying out the methods described herein—is suitable. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. The present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods.

[0181] Computer program means or computer program in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after conversion to another language, code or notation and/or reproduction in a different material form.

[0182] It is noted that the foregoing has outlined some of the more pertinent objects and embodiments of the present invention. This invention may be used for many applications. Thus, although the description is made for particular arrangements and methods, the intent and concept of the invention is suitable and applicable to other arrangements and applications It will be clear to those skilled in the art that other modifications to the disclosed embodiments can be effected without departing from the spirit and scope of the invention. The described embodiments ought to be construed to be merely illustrative of some of the more prominent features and applications of the invention. Other beneficial results can be realized by applying the disclosed invention in a different manner or modifying the invention in ways known to those familiar with the art.