`UNITED STATES PATENT AND TRADEMARK OFFICE
`_______________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`Petitioner,
`v.
`Patent Owner.
`______________
`
`ACHATES REFERENCE PUBLISHING, INC.
`
`_______________
`
`APPLE, INC.
`
`Case No.: IPR2013-‐00080 & IPR2013-‐00081
`
`Patents 6,173,403 & 5,289,889
`
`Before HOWARD B. BLANKENSHIP, JUSTIN T. ARBES, AND THOMAS L.
`GIANNETTI, Administrative Patent Judges.
`
`
`
`Declaration of Xin Wang
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`I, Xin Wang, do hereby declare and state, that all statements made
`herein of my own knowledge are true and that all statements made on
`information and belief are believed to be true; and further that these
`statements were made with the knowledge that willful false statements and
`the like so made are punishable by fine or imprisonment, or both, under
`Section 1001 of Title 18 of the United States Code.
`Dated: September 17, 2013
`
`/Xin Wang/
`
`
`
`
`
`
`Xin Wang
`
`
`
`
`
`2
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`I.
`II.
`III.
`IV.
`V.
`
`T A B L E O F C O N T E N T S
`
`Introduction ............................................................................................................ 4
`Qualifications ......................................................................................................... 4
`Summary of Conclusions ................................................................................... 6
`Legal Standards of Validity .............................................................................. 7
`Person of Ordinary Skill in the Art at the Time of Invention ............. 7
`
`
`
`3
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`I.
`
`Introduction
`
`I have been retained as an expert by Achates Reference Publishing,
`1.
`Inc., in connection with the above-‐captioned matter. This declaration
`represents my testimony in relation to U.S. Patent Nos. 5,982,889 (“’889
`patent”) and 6,173,403 (“’403 patent”) and specific matters that I was asked
`to address. In making this declaration, I relied upon the Exhibits entered in
`the above matter or submitted with this declaration. I also relied upon certain
`assumptions concerning patent law standards and concerning Grounds for the
`Initial Decisions, which I point out. I also reviewed the declarations of Mr.
`Schneier as well as some portions of his deposition, both of which I may
`reference in my declaration. For ease of reference, when I refer to the
`“Grounds” I refer to the rationale set forth in the Initial Decisions for
`instituting this proceeding.
`2.
`I am currently the Head of Multimedia Systems in Corporate
`Research of Huawei Technologies USA. I had been the chair of the Digital
`Rights Management (DRM) Workshop of the IEEE Consumer Communications
`and Networking Conference from 2007 to 2011, and adjunct faculty in
`Computer Science at the University of Southern California, Los Angeles,
`4
`
`Qualifications and Compensation
`
`II.
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`California, USA, since 1997. Before joining Huawei in 2009, I was the Chief
`Scientist of ContentGuard, Inc., a spin-‐off in the year of 2000 from the Xerox
`Palo Alto Research Center, based on the DRM project I had been working on
`since 1996. I was one of the key original contributors to the Microsoft DRM
`solution for Microsoft Office and other applications. I was also the editor of the
`ContentGuard’s XrML (eXtensible rights Markup Language), which is the base
`for the MPEG’s REL (Rights Expression Language) standard from 2001 to
`2005, and the primary author of the Contract Expression Language (CEL) for
`the Content Reference Forum from 2003 to 2006 which became an
`international ISO/IEC standard in 2012. I have over 17 years of industry
`experiences on DRM, security and system architecture. I am the inventor of
`more than 100 granted US and International patents, and over 50 US and
`International patent applications in these areas.
`3. My qualifications are stated more fully in my curriculum vitae,
`which is attached to this declaration as Appendix A.
`4.
`I am being compensated for my time spent reviewing materials,
`forming my opinions and in preparing this declaration at the rate of $375 per
`hour. My compensation is not contingent upon my testimony, the outcome of
`the proceeding or any testimony that I may give.
`5
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`Summary of Conclusions
`
`For the reasons I set forth below, I conclude that the claims 1-‐4 of
`5.
`the ‘889 patent are non-‐obvious over Pettitt in view of Beetcher and over
`Beetcher in view of Ginter; claim 1 of the ‘403 patent is novel over Pettitt:
`claims 2, 4, 5, 7 and 9 of the ‘403 patent are non-‐obvious over Pettitt in view of
`Beetcher; claims 17-‐19 of the ‘403 patent are novel over Beetcher; and claims
`1-‐12 of the ‘403 patent are non-‐obvious over Beetcher in view of Ginter and
`Bohannon, as applied in the Grounds.
`6.
`Also, for the reasons I set forth below, I conclude that a person of
`ordinary skill in the art (“POSA”) at the time of the invention would not have
`had reason to modify the prior art references in the manner stated in the
`Grounds. Without limiting my more detailed conclusions below, I determined
`that each of the prior art references embody specialized systems adapted to
`specific architectures to achieve different results employing different levels of
`technical complexity. The Grounds rely upon the declaration of Mr. Schneier.
`I have reviewed Mr. Schneier’s declaration with respect to making these
`combinations and his deposition testimony. I disagree with Mr. Schneier’s
`testimony that the functionality of any prior art system is interchangeable
`with any other prior art system. For reasons that I explain below, a POSA in
`6
`
`III.
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`IV.
`
`Legal Standards of Validity
`
`Person of Ordinary Level of Skill In the Art at the Time of Invention
`
`1996 or 1997 would not make the combinations relied upon in the Grounds
`that I considered.
`7.
`I reviewed the legal standards for validity as set forth in the
`declaration of Mr. Radbel, and I applied them in forming the opinions in this
`declaration. Attorneys for the Patent Owner asked me to assume and apply
`these standards.
`8.
`I reviewed the analysis and conclusion Mr. Radbel states in his
`declaration as it relates to the person of ordinary skill in the art (POSA) at the
`time of the invention. I agree with Mr. Radbel’s conclusions, and I apply them
`here. 9.
`In addition to the material Mr. Radbel identified, I also relied upon
`my own experience in determining the skill level of the POSA at the time of the
`invention. I worked in fields related to the invention beginning in 1996
`through the present, and, at the time of the invention, I was aware of skills of
`POSA. I have relied on and applied my knowledge and experience for
`purposes of determining a POSA and I make this declaration from the
`7
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`perspective of one having ordinary skill in the art at around the time of the
`invention as I have defined it above, unless I state otherwise.
`10.
`I also disagree with Mr. Schneier’s analysis that the POSA would
`have graduate level training, or comprehensive knowledge of cryptography,
`including Mr. Schneier’s book on the subject, for the reasons Mr. Radbel
`explains and as based upon my own experience..
`Anticipation Grounds Over Pettitt
`11.
`I next considered Pettitt as applied by the Grounds as anticipating
`claim 1 of the ‘403 patent. The Grounds rely upon the declaration of Mr.
`Schneier; therefore, I considered his declaration as well. Mr. Shchneier applied
`certain claim constructions that were not adopted in the Grounds. I applied
`the claim constructions in the Grounds.
`12. Apple contends that the encrypted reply envelope 34 comprises
`the LCH digital signature of the reply envelope, and, therefore, the decryption
`of the reply envelope recovers the LCH digital signature. Petition at 27-‐28.
`Apple relies upon the declaration of Mr. Schneier to support this contention.
`His declaration states:
`201. . . . the user is sent a reply envelope that comprises . . .
`the digital signature of the License Clearing House (“LCH”) . . .
`8
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`207. In Pettitt, if the request is accepted (for example,
`because the user has paid the appropriate fee), the LCH will create
`a reply envelope that includes, among other things, “information
`identifying the software,” “information identifying the user,” “a
`master key,” “the digital signature of the reseller,” a “digital
`authorization certificate,” and the digital signature of the LCH. Ex.
`1006 at 4:51-‐5:5, 5:21-‐24.
`208. The digital authorization certificate of Pettitt is an
`encrypted hash of the reply envelope. Ex. 1006 at 5:6-‐8.
`Ex. 1003 at ¶¶201, 207, 208. (emphasis supplied)
`13. Mr. Schneier’s declaration cites two portions of Pettitt to support
`his assertion. Ex. 1006 at 4:51-‐5:5, 5:21-‐24. The first portion is a list of the
`items that that the reply envelope includes – but the LCH digital signature is
`not on the list. Pettitt states:
`. . . LCH 14 creates reply envelope 34 through encryption in
`step 72. The reply envelope 34 includes:
`1.
`information identifying the software,
`2.
`information identifying the user,
`3.
`the digital signature of the reseller,
`4.
`the digital signature of the distributor,
`5.
`a master key that unlocks the software container 20
`(if the transaction has been authorized), and
`a digital authorization certificate.
`6.
`9
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`Ex. 1006 at 4:63-‐5:5.
`The digital signature of the reseller and the digital signature of the
`distributor are on the list, but the LCH digital signature of the reply envelope
`is not and cannot be, for the reasons below. Both the digital signature of the
`reseller and the digital signature of the distributor are created before the LCH
`digital signature is created, and, therefore, they are not a function of the LCH
`digital signature. The digital signature of the reseller is the reseller’s digital
`signature of the user’s authorization request 30, and it is created with the
`resellers’ private key. Ex. 1006 at 4:26-‐31. The digital signature of the
`distributor is the distributor’s digital signature of the user’s authorization
`request 30, and it is created with the distributor’s private key. Ex. 1006 at
`4:38-‐42. Both the digital signature of the reseller and the digital signature of
`the distributor are received by the license clearing house (LCH) 14. Ex. 4:44-‐
`50. Therefore, this confirms that neither of the digital signatures in the list is
`an alias of the LCH digital signature. I conclude that the reply envelope does
`not contain the LCH digital signature of the reply envelope. Ex. 1006 at 4:63-‐
`5:5. Moreover, I was able to determine that the reply envelop cannot even
`contain the LCH digital signature of the reply envelop itself, or in other words,
`10
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`the LCH digital signature cannot be placed inside the reply envelop itself. This
`is because the LCH digital signature would be an encrypted hash of the reply
`envelop that would include the signature, which is impossible. This further
`confirms that the reply envelop does not contain the LCH digital signature of
`the reply envelop.
`14. The second portion of Pettitt relied on for support describes that
`the license clearing house (LCH) signs the reply envelope.
`The LCH 14 also digitally signs the envelope with the
`signature of LCH 14 by hashing the contents of the reply envelope
`and encrypting the result of the hash with the LCH's private key.
`Ex. 1006, 5:21-‐24.
`However, creating an LCH digital signature does not show that the reply
`envelope 34 contains the signature, and decrypting the encrypted reply
`envelope 34 does not recover the LCH digital signature, either.
`15. The LCH digital signature of the reply envelope is available to
`reseller 17 before and independently of the decryption of the reply envelope,
`because Pettitt allows that “[a]s the reply envelope 34 is passed down from
`one entity to the next in the chain, each entity verifies the LCH 14 signature on
`the return envelope 34 in step 78 to check for authenticity” (Ex. 1006, 5:37-‐
`40), and requires that the reseller verify the LCH digital signature, all without
`11
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`the reply envelop being decrypted and before the reply envelope is decrypted.
`Therefore, the LCH digital signature is not recovered by decrypting the reply
`envelope. 16. Pettitt explains that decrypting the reply envelope 34 occurs after,
`and only if, the LCH signature is authenticated and indicates authorization:
`Once the reply envelope 34 is received by the reseller, the
`reseller 17 verifies the LCH 14 signature . . . If the LCH 14
`signature is authenticated and the result code indicates that the
`LCH 14 has authorized transaction, then the reseller 17 decrypts
`the reply envelope 34 using the reseller's [private] key, and
`passes the contents onto the user 18 in step 82.
`Ex. 1006, 5:45-‐55.
`This fact prevents the digital signature from being recovered by the
`decryption of the reply envelope.
`I was able to determine that reply envelope 34 is encrypted
`17.
`before the LCH digital signature is created. The license clearing house (LCH)
`14 encrypts the reply envelope with the public key of reseller 17 and
`thereafter signs the encrypted reply envelope (i.e., the LCH digital signature is
`based on the encrypted version of the reply envelope in contrast to the
`unencrypted version). Moreover, the fact that other entities are able to verify
`12
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`the LCH digital signature while the reply envelop is encrypted also shows that
`the LCH signature is on the encrypted envelop, and not on the clear-‐text reply
`envelop (Ex. 1006, 5:37-‐44). This means that the LCH digital signature is
`created after the reply envelope is encrypted or “sealed shut.” Therefore, the
`encrypted reply envelope does not include the information contained in the
`LCH digital signature, and the LCH digital signature is not recovered by
`decrypting the encrypted reply envelope.
`18.
`In the Petition for the ‘889 Patent, Apple also contends that the
`digital authorization certificate satisfies the claim 1’s “authentication code”
`limitation as a code for authenticating data. Pettitt describes two purposes for
`the digital authorization certificate, neither of which is for authenticating data.
`First, “user 18 then uses the authorization certificate and the master key to
`unlock the software container 20 and install the software.” Second, it is used
`by the user as a proof-‐of-‐purchase certificate that enables author 12 “to
`distinguish authorized users from unauthorized users.” Pettitt states:
`The user 18 then uses the authorization certificate and the
`master key to unlock the software container 20 and install the
`software in step 84. . . . .
`The present invention is not intended to stop illegal copying
`of the software once it is unlocked. The present invention does,
`13
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`however, provide the author 12 with a mechanism to distinguish
`authorized users from unauthorized users.
`
`Ex. 1006, 5:56-‐6:13. (emphasis supplied)
`Neither of these functions use the digital authorization certificate for the
`purpose of authenticating data.
`19. With regard to the second purpose, a person of ordinary skill in
`the art would know that Pettitt does not work. Pettitt teaches that author 12
`distinguishes authorized users from unauthorized users by generating a new
`digital authorization certificate to compare with the one received from the
`user.
`To determine whether a particular user 18 is authorized,
`the author 12 may request the original authorization certificate
`from the user 18. If the user 18 cannot provide it, then the user
`18 has no proof that s/he is an authorized user. If the user 18
`provides the author 12 with an original authorization certificate,
`then the author 12 takes the identity of the user 18 and derives a
`new authorization certificate. This new authorization certificate
`is then compared to the original authorization certificate. If the
`new authorization certificate does not match the original
`authorization certificate, then the author 12 may conclude that
`the person is an unauthorized user.
`Ex. 1006, 5:56-‐6:13. (emphasis supplied)
`14
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`This is not possible without foiling the principal objective of Pettitt, which is:
`According to the system and method disclosed herein, the
`only trusted entity in the distribution chain is the license clearing
`house, all other entities including the author of the software are
`incapable of generating authorization certificates.
`Ex. 1006, 5:6-‐8 and 5:21-‐24.
`20. This is because generation of both the digital authorization
`certificate and the LCH digital signature requires the licensing clearing house
`(LCH) 14 private key.
`The digital authorization certificate is generated by hashing
`the above-‐identified information and encrypting it with the LCH's
`a private key.
`* * * The LCH 14 also digitally signs the envelope with the
`signature of LCH 14 by hashing the contents of the reply envelope
`and encrypting the result of the hash with the LCH's private key.
`Ex. 1006, 5:6-‐8 and 5:21-‐24.
`Therefore, if the LCH private key were divulged to author 12, then the
`principal objective of Pettitt would be foiled. For this reason, Pettitt’s digital
`authorization certificate does not serve the purpose to distinguish authorized
`15
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`users from unauthorized users. Even it did, the digital authorization certificate
`is not for authenticating data, and hence is not an authentication code.
`21. Also, as I explained above, Pettitt explicitly teaches that reseller
`17 must authenticate the encrypted reply envelope with the LCH digital
`signature before the reseller decrypts the reply envelope. Pettitt states:
`Once the reply envelope 34 is received by the reseller, the
`reseller 17 verifies the LCH 14 signature, . . . If the LCH 14
`signature is authenticated and the result code indicates that the
`LCH 14 has authorized transaction, then the reseller 17 decrypts
`the reply envelope 34 using the reseller's [private] key, and
`passes the contents onto the user 18 in step 82.
`Ex. 1006 at 5:45-‐55.
`22. Therefore, if the encrypted reply envelope is authenticated with
`the LCH digital signature before decrypting the reply envelop, thereby
`recovering the digital authorization certificate, then authenticating the reply
`envelope does not even use the digital authorization certificate. For this
`reason, Pettitt’s digital authorization certificate is not an authentication code,
`but a piece of information used along with the master key to unlock the
`software container and a piece of information used to distinguish authorized
`from unauthorized users (as Petit explicitly states).
`16
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`23. When considering the name of the digital authorization certificate
`and the two purposes for which it is used, a person of ordinary skill in the art
`would not consider the digital authorization certificate to be an authentication
`code, a code for authenticating data.
`24.
`I next address the Grounds stated for claim 17-‐19 of the ‘403
`patent, which apply Beetcher. I note that the Grounds rely upon Mr. Schneier’s
`declaration, and that Mr. Schneier relied upon constructions of installing and
`authentication code that the Grounds did not adopt. Mr. Schneier’s declaration
`does not provide a comparison of Beetcher to properly construed claims as I
`understand an anticipation analysis requires. For this reason I conclude Mr.
`Schneier’s declaration does not support anticipation. I apply the correctly
`construed claims in my review of Mr. Schneier’s declaration.
`25. Claim 17 recites
`17. A method comprising:
`reading an encrypted token from a computer;
`decrypting said encrypted token with a string, T, as the key
`to recover a token that comprises an indicium of a first
`information product;
`17
`
`modifying said token to comprise an indicium of a second
`
`Anticipation Grounds Over Beetcher
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`information product;
`encrypting said token with said string, T, as the key to
`create a newly encrypted token; and
`storing said newly encrypted token on said computer.
`(emphasis supplied)
`26. Beetcher describes a system that distributes an “encrypted
`entitlement key [that] enables execution of [] software” (Beetcher '497 at 4:4).
`The entitlement key consists of, among other things, a machine serial number
`and 80-‐bit “product entitlement flags” (Beetcher '497 Figure 2). The latter are
`a series of binary flags, each of which is set to 1 if the computer is entitled to
`run that software product or 0 if not. (Beetcher '497 at 6:36-‐40.) A software
`distributor sends the encrypted entitlement keys to users, who may type them
`in. (Beetcher '497 at 5:60-‐64.)
`27. The entitlement keys are stored in a “product key table” in
`memory. The product key table contains entries that include encrypted
`entitlement keys (see above), date/time of the product key’s first use, and a
`“charge group” that determines pricing of the software (Beetcher '497 at 6:24-‐
`26). Only the entitlement keys in product key table entries are encrypted. The
`user’s computer also maintains a “product lock table” that stores entitlement
`keys (Beetcher '497 at 4:11-‐12) (Beetcher '497, Figure 9b).
`18
`
`
`
`Apple v. Achates
`IPR2013-00081
`Achates Ex. 2014
`
`
`
`28. Execution of programs on the user’s computer is controlled by
`means of “entitlement verification triggers,” which are single machine
`instructions embedded in the code of software programs to be run. They are
`embedded during the process of compiling the software into machine code,
`i.e., before the software is distributed (Beetcher '497, Figure 7 and 9:1-‐20).
`When the
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
