A common way to distribute a document to various sources is by means of an electronic form of the document. Several methods exist for an original source to distribute such a digital document to other users, such as by email with the digital document as an attachment, by providing a link from which the user may download the digital document, or by saving the digital document to a network that the user may access. Upon receiving and reviewing the digital document, the user may sign the digital document and return the digital document to the original source.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
Various embodiments related to parallel document processing are disclosed herein. One disclosed embodiment includes a method of processing documents distributed in parallel. First, one or more digital document packages are received, where each digital document package includes a content portion and an identity-verification code (IVC) verifying an identity of a source from which the digital document package is received. Each IVC may be a private-key encryption of a content-verification code hashed from the content portion of each digital document package. Next, a master digital document package is created, which includes a master content portion equivalent to the content portion in each unmodified digital document package, and one or more different IVCs, each IVC obtained from a digital document package received from a different source.
As discussed above, the content-verification code results from applying a hash function to the digital document package. The hash function receives as input the digital document package, or at least a content portion thereof, and outputs a string, namely the content-verification code. Such a content-verification code has a unique correspondence to the digital document package in that equivalent digital document packages will yield the same content-verification code, whereas different digital document packages will yield different content-verification codes. Furthermore, although it may be straightforward to generate the content-verification code from the digital document package, the reverse approach of constructing a digital document package from a content-verification code should be nearly impossible in practice.
Upon encryption with a private key, the content-verification code becomes an IVC. Such an encryption follows a public-key cryptography methodology, where a key used to encrypt a message differs from a key used to decrypt the encrypted message. In public-key cryptography, a user is assigned a pair of cryptographic keys, namely a public key and a private key. The private key is kept secret, while the public key may be widely distributed by any suitable means. The keys are related mathematically, but the private key may not be practically derived from the public key.
The IVC may be added to a digital document package according to a predetermined set of processing rules and syntax for creating and adding the IVC to the digital document package. Furthermore, the IVC may be added to a digital document package via an application utilizing such processing rules and syntax. As described in more detail below, the same or different applications may use the same processing rules and syntax for aggregating two or more IVCs into a master document.
Returning to
The digital certificate may be issued by a trusted certification authority, where the trusted certification authority guarantees the validity of the digital certificate and guarantees that the public key accessible via the digital certificate corresponds to the source of the digital certificate. Furthermore, the digital certificate includes a certification authority identity-verification code corresponding to the trusted certification authority. Anyone who obtains the digital certificate may then examine the digital certificate to confirm that it was issued by a trusted certification authority.
At 16, method 10 includes decrypting the IVC using the public key to yield a decrypted IVC. At 18, method 10 includes comparing the decrypted IVC to a master content-verification code. The master content-verification code may be calculated by hashing a master content portion of a master digital document package. The master digital document package being a digital document package into which the IVCs may be merged at a later step. The master content portion is equivalent to an original content portion of an original digital document package sent to the source.
The purpose of this step is to determine if the source modified the content portion of the digital document package when adding their IVC. If the source did not change the content portion of the digital document package when adding their IVC, decrypting this IVC at 16 yields a decrypted IVC equivalent to the master content-verification code, in which case method 10 further includes, at 20, merging the IVC into the master digital document package.
Merging the IVC into the master digital document package may comprise updating a table of contents of the master digital document package, the table of contents indexing each of the IVCs of the master digital document package.
Next, at 22 method 10 comprises determining if there are any other IVCs that are to be added to the master digital document package. If so, method 10 loops to 12 to start method 10 again. If there are no more IVCs to add to the master digital document package at 22, then method 10 ends.
If method 10 at 18 instead determines that the decrypted IVC is not equivalent to the master content-verification code, then the IVC may be rejected and not merged into the master digital document package. In this case, method 10 bypasses 20 and continues to 22 described above.
In some embodiments, the digital document package 40 may be sent to the users according to a signing policy. Such a signing policy may indicate restrictions on who may add an IVC to the digital document package, so that the digital document package cannot be forwarded to unintended participants who could then add an unwanted IVC.
At 42, upon receiving and validating that a content portion received from each user is equivalent to the original content portion COriginal, now re-named the master content portion CMaster, the IVCs may be merged into the master digital document package, yielding a master digital document package 44. As such, each merged IVC may independently verify an identity of the source from which that digital document package is received.
In other embodiments, upon receiving a content portion from each user, the IVCs may be merged into the master digital document package without validating the IVCs prior to merging. This yields a master digital document package including a master content portion equivalent to the content portion in each unmodified digital document package, and a plurality of different IVCs, each identity-verification code obtained from a digital document package received from a different source. In such embodiments, an IVC corresponding to each unmodified digital document package is valid whereas an IVC corresponding to a modified digital document package is invalid.
Thus, the master digital document package 44 includes a master content portion CMaster, equivalent to the original content portion COriginal, and a plurality of different IVCs, each IVC obtained from a digital document package received in parallel from a different user.
Upon receiving the digital document packages at 58, each IVC may be decrypted with the public key corresponding to that user. For example, IVC Sn may be decrypted with public key Kn corresponding to user n. Each decrypted IVC (e.g., h1, h2 and hn) may then be compared to the content-verification code HMaster, hashed from the master content portion CMaster. If a decrypted IVC (e.g., h1, h2 and/or hn) is determined to be equivalent to the content-verification code HMaster, then the decrypted IVC (e.g., h1, h2 and/or hn) may be accepted and the corresponding IVC (e.g., S1, S2 and/or Sn) may be merged into the master digital document package. If a decrypted IVC (e.g., h1, h2 and/or hn) is determined to be different than the content-verification code HMaster, then the decrypted IVC (e.g., h1, h2 and/or hn) may be rejected and the corresponding IVC (e.g., S1, S2 and/or Sn) may be left out of the master digital document package. In this way, it can be ensured that the master document will only include IVCs from individuals that did not change the content of the original document. In other words, all IVCs packaged in the master document are based on the same content.
It should be understood that the configurations and/or approaches described herein are exemplary in nature, and that these specific embodiments or examples are not to be considered in a limiting sense, because numerous variations are possible. The specific routines or methods described herein may represent one or more of any number of processing strategies. As such, various acts illustrated may be performed in the sequence illustrated, in other sequences, in parallel, or in some cases omitted. Likewise, the order of the above-described processes may be changed.
The subject matter of the present disclosure includes all novel and nonobvious combinations and subcombinations of the various processes, systems and configurations, and other features, functions, acts, and/or properties disclosed herein, as well as any and all equivalents thereof.