Pre-Grant Publication Number: 20070160202
Collaborate on the process of community review for this application. Posting will not be forwarded to the USPTO.
Flagging a post as an ACTION ITEM signals further research. Flagging SPAM and ABUSE helps to manage discussion.
Placing double brackets around a reference to a claim or prior art will create a hyperlink to the original
ex. [[claim 1]] and [[prior art 2]].
Facilitator's Comment 
Action Item Show without Noise
0 days left
"wherein the encryption key is a public key; and
wherein the decryption key is a private key."
Assuming that <decription key> and <??description key??> are the same thing, then this means that the decryption key is used to decrypt the user data key. In the state of the art, this is the KEK.
The user data is decrypted with the user data key. In the state of the art, this is the CEK.
In Claim 0001 the CEK layer could be either symmetric or asymmetric. In this case, the CEK layer is defined to be an asymmetric crypto algorithm.
Many specifications (including S/MIME) have two layers: message encrypted with symmetric key
symmetric key encrypted with public key (May 2002) Slide 11
www.rsa.com/rsalabs/staff/bios/bkaliski/publications/other/kaliski-key-encapsulation-rsa-2002j.ppt
Slide 30 shows all the standards that use key encapsulation (message encrypted with symmetric key symmetric key encrypted with public key)
Slide 16 shows the integrity concept was already understood in 2002.
"decrypting the encrypted [user data key] with a <decryption key> in response to an initiation of a decryption of the encrypted user data with the [user data key] as decrypted with the <??description key??>;
decrypting a verification text with the [user data key] as decrypted with the <decryption key>;
validating a use of the [user data key] as decrypted with the <decryption key> to decrypt the encrypted user data in response to a matched comparison of the verification text as decrypted with the [user data key] and an intermixing of a known text and a random text; and
invalidating the use of the [user data key] as decrypted with the <decryption key> to decrypt the encrypted user data in response to a mismatched comparison of the verification text as decrypted with the [user data key] and the intermixing of the known text and the random text."
I am a bit confused by their intermixed use of <decryption key> and <??description keys??>. I have to assume it's a typo that a spell checker would not find and assume that <decryption key> and <??description key??> are really the same thing. This needs to be clarified.
"decrypting the first grouping of the first known text segment and the first random text segment with the user data key as decrypted with the decryption key; and
decrypting the second grouping of the second known text segment and the second random text segment with the user data key as decrypted with the decryption key."
This looks like the decryption counterpart of claim 5. Obvious
"encrypting a first grouping of a first known text segment and a first random text segment with the user data key prior to the encryption of the user data key with the encryption key;
encrypting a second grouping of a second known text segment and a second random text segment with the user data key prior to the encryption of the user data key with the encryption key; and
storing the verification text including the encrypted first grouping of the first known text segment and the first random text segment and the encrypted second grouping of the second known text segment and the second random text segment. "
This looks like a re-hash of claim 4
"wherein the verification text includes a first verification segment, a second verification segment, a third verification segment and a fourth verification segment in sequential order;
wherein the first verification segment includes an encryption of a first random text segment with the user data key prior to the encryption of the user data key with the encryption key;
wherein the second verification segment includes an encryption of a first known text segment with the user data key prior to the encryption of the user data key with the encryption key;
wherein the third verification segment includes an encryption of a second known text segment with the user data key prior to the encryption of the user data key with the encryption key; and
wherein the fourth verification segment includes an encryption of a second random text segment with the user data key prior to the encryption of the user data key with the encryption key. "
The additional claims being made on their mixing function with the salt are being claimed here. Their description of Figure 3 and 4 and stage S54 of flowchart 50 does not tell us much more detail and why they are doing this. I see no real novelty here. It's just interlacing the salt with the verification string.
"segment the intermixing of the known text and the random text;
encrypting the segmented intermixing of the known text and the random text with the user data key prior to the encryption of the user data key with the encryption key, wherein the verification text is the segmented intermixing of the known text and the random text in segments as encrypted with the user data key. "
is encrypting the segmented integrity check and a salt with the CEK then encrypting the contents with the CEK
This is still extremely broad. They don't specify asymmetric or symmetric crypto, they specify a little more of their mixing function, they don't specify whether there is additional data combined with the integrity check nor do they specify what is to be done at the receiving end.
I'm not sure as to how novel chopping up the integrity check into bits is. Their description of stage S54 does not tell us what the purpose for doing this. Perhaps it is a security feature so that the string of know text is not too long, etc.
"encrypting the intermixing of the known text and the random text with the user data key prior to the encryption of the user data key with the encryption key, wherein the verification text is the encrypted intermixing of the known text and the random text."
encrypting the integrity check and a salt with the CEK then encrypting the contents with the CEK
This is still extremely broad. They don't specify asymmetric or symmetric crypto, they don't specify the mixing function, they don't specify whether there is additional data combined with the integrity check nor do they specify what is to be done at the receiving end.
Salting the integrity check is obvious. But here it's being discussed in Feb 1999 in an S/Mime discussion: http://www.imc.org/ietf-smime/archive1/msg02568.html
Salts are often used in combination with passwords for encryption, combining a random text with a known text, something very similar to what they're describing in Claim 3.
If you look at Claim 00001, the claim mentions decryptions without saying anything about the cipher type being asymmetric, symmetric or hybrid. So their claim is so broad that it claims wraps, encapsulation, and a hybrid encapsulation. In comparison, their description is much narrower.
If the independent claims (Claim 00001, Claim 00008 and Claim 00015) cannot stand on their own, then there is no need to look at dependent claims like claim 2 and 3... They are patenting something as broad as using an unwrapped key to decrypt the integrity check message in [Claim 00001].
I think it should be very straight forward to find prior art for the three cases - asymmetric, symmetric and hybrid.
Most prior art will address the normal case that the CEK is symmetric and the KEK is a public key. This will address both claim 1 and 7.
However, the purpose of dependent claims is to survive even if the broader independent claims are knocked out. So if the independent claims are rejected, it is still possible that the dependent claims would be allowed.
Nevertheless, I would concentrate on art to address the independent claims 1, 8 and 15. I'd expect that the art will clearly specify asymmetric encryption at the outer layer with the KEK being a public key and the corresponding decryption key a private key. Thus claims 7, 14 and 21 should also be addresssed automatically. Beyond that, I hope that the examiner will conclude that the variations introduced in the other claims are the kind of straightforward variations that one would expect from a person having ordinary skill in the art.
Be careful not to go down the wrong tangent with searches on key encapsulation. It is often used for a variation that doesn't involve encrypting the CEK with the KEK.
User data key to me means a public-private key pair. Are they using the accepted terminology?
However this same process takes place when an EDI document is sent via a virtual private network, or an MD5 checksum is run against a file downloaded with a secure socket layer.
The EDI document has built in checks for element counts, item counts and so on.
Extension of this process, such as in the case of automated updates, where a file or patch is downloaded via SSL and the document is validated at the receiving end is obvious. A patent that would close off development of logical extensions of this process should fail the obviousness test.
It may well be that update programs for Firefox or Ubuntu already have this functionality, and I am not aware of it.