UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`
`Petitioner,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`
`Patent Owner.
`
`_________________________________________
`
`Case IPR2018-00813
`
`U.S. Patent No. 9,100,826
`
`________________________________________
`
`DECLARATION OF ARI JUELS
`
`Apple 1120
`Apple v. USR
`IPR2018-00813
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`
`Petitioner,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`
`Patent Owner.
`
`_________________________________________
`
`Case IPR2018-00813
`
`U.S. Patent No. 9,100,826
`
`________________________________________
`
`DECLARATION OF ARI JUELS
`
`Apple 1120
`Apple v. USR
`IPR2018-00813
`
`
`
`(cid:2)(cid:5)(cid:4)(cid:7)(cid:3)(cid:4)(cid:7)(cid:6)(cid:1)
`
`I. QUALIFICATIONS ....................................................................................... 1(cid:1)
`II. LEGAL PRINCIPLES .................................................................................... 3(cid:1)
`A.
`Claim Construction .................................................................................... 3(cid:1)
`B. Anticipation ............................................................................................... 4(cid:1)
`C. Obviousness .............................................................................................. 5(cid:1)
`D.
`Person of Ordinary Skill In The Art ........................................................... 9(cid:1)
`III. THE ’585 REFERENCE .............................................................................10(cid:1)
`A. Overview ..................................................................................................10(cid:1)
`B.
`The ’585 Reference Discloses An Authentication System For Financial
`Transactions ......................................................................................................16(cid:1)
`C.
`The ’585 Reference Is Not Limited To One-Way Functions .....................18(cid:1)
`D. Contrary to Dr. Jakobsson’s Testimony, The ’585 Reference Discloses
`“Retrieving Or Receiving” Second Authentication Information.........................21(cid:1)
`E.
`The ’585 Reference Discloses Performing A Local Biometric
`Authentication ...................................................................................................25(cid:1)
`F. Event States Are Not “Always Sent” ...........................................................27(cid:1)
`IV. AVAILABILITY FOR CROSS-EXAMINATION ......................................29(cid:1)
`V. RIGHT TO SUPPLEMENT ...........................................................................29(cid:1)
`VI.
`JURAT ........................................................................................................29(cid:1)
`
`ii
`
`
`
`I, Ari Juels, declare as follows:
`
`1.
`
`I have been retained by Apple Inc. (“Petitioner”) in connection with
`
`the above-captioned inter partes review proceeding.
`
`2.
`
`I am a named inventor of the International Patent Application
`
`Publication No. WO 2004/051585 (the “’585 reference” which is also referred to
`
`elsewhere in this proceeding as the “Jakobsson” reference). I submit this
`
`Declaration to respond to the statements and opinions provided by Markus
`
`Jakobsson, my co-inventor on the ’585 reference and Patent Owner’s expert
`
`witness. In my opinion, Dr. Jakobsson grossly mischaracterizes the ’585 reference
`
`and has interpreted its teachings in a way that is inconsistent with the purpose,
`
`spirit, and words of the ’585 reference. In addition, his testimony includes
`
`numerous misleading and/or technically incorrect statements that I rebut in the
`
`following paragraphs.
`
`3.
`
`I am being compensated at my normal consulting rate for my work.
`
`My compensation is not dependent on the outcome of this proceeding or the related
`
`litigation, and does not affect the substance of my statements in this Declaration. I
`
`have no financial interest in Petitioner or the ’826 patent.
`
`I.
`
`QUALIFICATIONS
`
`4.
`
`My qualifications are detailed in my curriculum vitae, which is
`
`attached hereto as Appendix A. It includes my academic background, employment
`1
`
`
`
`history, professional experience, and a list of patents and publications for which I
`
`am an inventor and/or author.
`
`5.
`
`I am a full professor at the Jacobs Technion-Cornell Institute at
`
`Cornell Tech, with an associated faculty appointment at Cornell University. I have
`
`been on the faculty at Cornell Tech and regularly taught master’s and Ph.D.-level
`
`courses since 2014. I am also a Co-Director of the Initiative for CryptoCurrencies
`
`and Contracts (IC3). I served previously as Chief Scientist at RSA, where I
`
`worked for over sixteen years. I received my Ph.D. in computer science from the
`
`University of California at Berkeley in 1996.
`
`6.
`
`I hold over 120 issued patents and have published over 100 scholarly
`
`works in peer-reviewed venues. According to Google Scholar, my work has
`
`received over 30,000 citations; four of my papers are among the top hundred most
`
`cited in security. My notable awards over the past ten years include a 2nd-place
`
`prize at the EMC Innovation Showcase in 2011, NYU-Poly Applied Security paper
`
`awards (3rd and 2nd) in 2012 and 2013, my winning the Cisco Internet of Things
`
`Security Grand Challenge in 2014, a Google Faculty Research Award in 2015, an
`
`IBM Faculty Research Award in 2016, Distinguished Student Paper Awards in
`
`2015 and 2016 from IEEE S&P (a top-four international security conference), a
`
`faculty teaching award at Cornell Tech in 2018, and a test-of-time award in 2019
`
`2
`
`
`
`from NDSS (a top-four international security conference, where I also gave the
`
`keynote talk in 2018).
`
`7.
`
`In preparing this Declaration, I have reviewed the following materials:
`
`(cid:120) Petition (Paper 3) and the exhibits cited therein
`
`(cid:120) U.S. Patent No. 9,100,826 (Ex-1101)
`
`(cid:120) Patent Owner’s Response (Paper 18) (“POR”) and the exhibits cited therein
`
`(cid:120) WO 2004/051585 (the “’585 reference”) (Ex-1104)
`
`(cid:120) Declaration of Markus Jakobsson in Support of Patent Owner Response (Ex-
`2101) and the exhibits cited therein
`
`(cid:120) Transcript of March 20, 2019 deposition of Markus Jakobsson (Ex-1117)
`LEGAL PRINCIPLES
`
`II.
`
`8.
`
`I am not an attorney. For purposes of this Declaration, I have been
`
`informed about certain aspects of the law that are relevant to my analysis and
`
`opinions.
`
`A.
`
`9.
`
`Claim Construction
`
`I have been informed that claim construction is a matter of law and
`
`that the final claim construction will ultimately be determined by the Board.
`
`10.
`
`I have been informed that the claim terms in an IPR review should be
`
`given their broadest reasonable construction in light of the specification as
`
`commonly understood by a person of ordinary skill in the art (“POSITA”). I have
`
`applied this standard in my analysis. I have been informed that the broadest
`
`3
`
`
`
`reasonable interpretation must be consistent with the ordinary and customary
`
`meaning of the term (unless the term has been given a special definition in the
`
`specification). I have also been informed and understand that the broadest
`
`reasonable interpretation must be consistent with the use of the claim term in the
`
`specification and drawings and must be consistent with the interpretation that those
`
`skilled in the art would reach.
`
`11.
`
`I have been informed and understand that under a broadest reasonable
`
`interpretation, words of the claim must be given their plain meaning, unless such
`
`meaning is inconsistent with the specification. The plain meaning of a term means
`
`the ordinary and customary meaning given to the term by those of ordinary skill in
`
`the art at the time of the invention.
`
`B.
`
`12.
`
`Anticipation
`
`I have been informed and understand that a patent claim is invalid as
`
`“anticipated” if each element of that claim is present either explicitly or inherently
`
`in a single prior art reference.
`
`13.
`
`I have been informed that, under the principle of inherency, a prior art
`
`reference may anticipate a claimed invention even if the reference does not
`
`expressly disclose every limitation of the later invention, so long as any limitation
`
`not expressly disclosed is necessarily present in the reference. I have also been
`
`informed that to be an inherent disclosure, the limitation must necessarily be
`
`4
`
`
`
`contained in the prior art reference and the mere fact that the method or system
`
`described in the reference might possibly (or sometimes) practice or contain a
`
`claimed limitation is insufficient to establish that the reference inherently teaches
`
`the limitation.
`
`14.
`
`I have been informed that material not explicitly contained in a single,
`
`prior art document may still be considered for purposes of anticipation if that
`
`material is incorporated by reference into the prior art document.
`
`15.
`
`I have also been informed and understand that a prior art reference is
`
`considered enabling when the reference permits a POSITA to make and use the
`
`disclosed technology without having to conduct undue experimentation. However,
`
`some amount of experimentation to make and use the invention is allowable.
`
`C.
`
`16.
`
`Obviousness
`
`I have been informed and understand that a patent claim can be
`
`considered to have been obvious to a POSITA at the time the application was filed.
`
`This means that, even if all the requirements of a claim are not found in a single
`
`prior art reference, the claim is not patentable if the differences between the subject
`
`matter in the prior art and the subject matter in the claim would have been obvious
`
`to a POSITA at the time the application was filed.
`
`5
`
`
`
`17.
`
`I have been informed and understand that a determination of whether
`
`a claim would have been obvious should be based upon several factors, including,
`
`among others:
`
`(cid:120) the level of ordinary skill in the art at the time the application was
`
`filed;
`
`(cid:120) the scope and content of the prior art; and
`
`(cid:120) what differences, if any, existed between the claimed invention and
`
`the prior art.
`
`18.
`
`I have been informed and understand that the teachings of two or
`
`more references may be combined in the same way as disclosed in the claims, if
`
`such a combination would have been obvious to a POSITA. In determining
`
`whether a combination based on either a single reference or multiple references
`
`would have been obvious, it is appropriate to consider, among other factors:
`
`(cid:120) whether the teachings of the prior art references disclose known
`
`concepts combined in familiar ways, and when combined, would yield
`
`predictable results;
`
`(cid:120) whether a POSITA could implement a predictable variation, and
`
`would see the benefit of doing so;
`
`6
`
`
`
`(cid:120) whether the claimed elements represent one of a limited number of
`
`known design choices, and would have a reasonable expectation of
`
`success by those skilled in the art;
`
`(cid:120) whether a POSITA would have recognized a reason to combine
`
`known elements in the manner described in the claim;
`
`(cid:120) whether there is some teaching or suggestion in the prior art to make
`
`the modification or combination of elements claimed in the patent;
`
`and
`
`(cid:120) whether the innovation applies a known technique that had been used
`
`to improve a similar device or method in a similar way.
`
`19.
`
`I have been informed and understand that a POSITA has ordinary
`
`creativity, and is not an automaton.
`
`20.
`
`I have been informed and understand that in considering obviousness,
`
`it is important not to determine obviousness using the benefit of hindsight derived
`
`from the patent being considered.
`
`21.
`
`I have been informed and understand that certain factors may support
`
`or rebut the obviousness of a claim. I understand that such secondary
`
`considerations include, among other things, commercial success of the patented
`
`invention, skepticism of those having ordinary skill in the art at the time of
`
`invention, unexpected results of the invention, any long-felt but unsolved need in
`
`7
`
`
`
`the art that was satisfied by the alleged invention, the failure of others to make the
`
`alleged invention, praise of the alleged invention by those having ordinary skill in
`
`the art, and copying of the alleged invention by others in the field. I understand
`
`that there must be a nexus, that is, a connection, between any such secondary
`
`considerations and the alleged invention. I also understand that contemporaneous
`
`and independent invention by others is a secondary consideration tending to show
`
`obviousness.
`
`22.
`
`I have been informed and understand that a claim would have been
`
`obvious if it unites old elements with no change to their respective functions, or
`
`alters prior art by mere substitution of one element for another known in the field,
`
`and that combination yields predictable results. Also, I understand that
`
`obviousness does not require physical combination/bodily incorporation, but rather
`
`consideration of what the combined teachings would have suggested to persons of
`
`ordinary skill in the art at the time of the alleged invention.
`
`23.
`
`I have been informed and understand that while it may be helpful to
`
`identify a reason for this combination, there is no rigid requirement of finding an
`
`express teaching, suggestion, or motivation to combine within the references.
`
`When a product is available, design incentives and other market forces can prompt
`
`variations of it, either in the same field or a different one. If a person of ordinary
`
`skill in the art can implement a predictable variation, obviousness likely bars its
`
`8
`
`
`
`patentability. For the same reason, if a technique has been used to improve one
`
`device and a person of ordinary skill in the art would recognize that it would
`
`improve similar devices in the same way, using the technique would have been
`
`obvious. I understand that a claim would have been obvious if a person of
`
`ordinary skill in the art would have had reason to combine multiple prior art
`
`references or add missing features to reproduce the alleged invention recited in the
`
`claims.
`
`D.
`
`24.
`
`Person of Ordinary Skill In The Art
`
`I have been informed that a POSITA is a hypothetical person to whom
`
`an expert in the relevant field could assign a routine task with reasonable
`
`confidence that the task would be successfully carried out. I understand that the
`
`level of ordinary skill may be reflected by the prior art of record, and that a person
`
`of ordinary skill in the art to which the claimed subject matter pertains would have
`
`the capability of understanding the scientific and engineering principles applicable
`
`to the pertinent art. I understand that one of ordinary skill in the art has ordinary
`
`creativity, and is not an automaton robot.
`
`25.
`
`I understand there are multiple factors relevant to determining the
`
`level of ordinary skill in the art, including: (1) the levels of education and
`
`experience of persons working in the field at the time of the invention; (2) the
`
`9
`
`
`
`sophistication of the technology; (3) the types of problems encountered in the field;
`
`and (4) the prior art solutions to those problems
`
`26. At the time the ’826 patent was effectively filed, a POSITA would
`
`have had a Bachelor’s Degree in electrical engineering, computer science, or a
`
`related scientific field. A POSITA would also have approximately two years of
`
`work experience in the computer science field or a related scientific field such as
`
`operating systems, database management, encryption, security algorithms, and
`
`secure transaction systems. However, additional education could substitute for less
`
`work experience and vice versa.
`
`27.
`
`Based on my experience, I have an understanding of the capabilities
`
`of a person of ordinary skill in the relevant field. I have supervised and directed
`
`many such persons over the course of my career. Further, I had at least those
`
`capabilities myself at the time the patent was filed.
`
`III. THE ’585 REFERENCE
`
`A.
`
`28.
`
`29.
`
`Overview
`
`I am a named inventor of the ’585 reference.
`
`The ’585 reference is titled “Identity Authentication System and
`
`Method,” and discloses a variety of methods for authenticating a user for a variety
`
`of applications. Specifically, it describes means by which what are referred to as
`
`event states, may be transmitted to a receiver through embedding in authentication
`
`10
`
`
`
`codes. Event states, which is information about the state of the device associated
`
`with the occurrence or non-occurrence of an event, are, broadly speaking, data that
`
`usefully informs the process of authenticating users. They can include anything
`
`from reports on token tampering to biometric authentication results. The benefit of
`
`embedding event states in authentication codes is that the event states can provide
`
`context for these codes and/or supplement them with additional authentication
`
`information that can lead to higher-fidelity user authentication. In the exemplary
`
`embodiment disclosed in Figure 1, the ’585 reference discloses a user 110 using
`
`user authentication 120 can communicate with a verifier 105.
`
`Ex-1104, ’585 reference, FIG. 1.
`
`30.
`
`The ’585 reference discloses that the user can be authenticated at the
`
`user authentication device 120 (i.e., a “local authentication”). See Ex-1104, ’585
`
`11
`
`
`
`reference, [0059] (“a first authentication of user 110 is performed by the user
`
`authentication device 120 based on information supplied to the authentication
`
`device 120 by the user 110.”). This local authentication is usually performed by
`
`comparing a value received from the user with a value stored by the user
`
`authentication device 120. These values can comprise PINs, passwords, or
`
`biometric information. Id. (“the information supplied by the user may be a PIN, a
`
`password or biometric information”).
`
`31. The ’585 reference also discloses various methods for authenticating
`
`the user with the verifier 105 (i.e., a “remote authentication”). These methods
`
`generally involve generating an authentication code using the user authentication
`
`device 120 that is sent to the verifier. The verifier validates the authentication code
`
`generated by the user authentication device 120 to authenticate the user 110. As
`
`illustrated in Figure 2, the ’585 reference discloses that the user authentication
`
`device 120 uses a number of different algorithms performed by the combination
`
`function 230 to generate an authentication code.
`
`12
`
`
`
`Ex-1104, ’585 reference, FIG. 2.
`
`32. As shown in Figure 2, the combination function combines various
`
`inputs to generate an authentication code. Ex-1104, ’585 reference, [0060]
`
`(“various values are combined by a combination function 230 to generate an
`
`authentication code . . . .”). These values include “device secret (K) associated
`
`with the user authentication device 120, a dynamic, time- varying value (T)
`
`generated by the user authentication device 120, and an event state (E) representing
`
`the occurrence of one or more events.” Id. The user authentication device 120 can
`
`also use various forms of user data called “User Data (P)” as an input to the
`
`combination function 230. Id., [0072] (“User data (P) can also be provided as
`
`input to the combination function 230.”). User Data (P) includes PINs, passwords,
`
`and biometric information. Id. (“The user data (P) is a unit of information such as
`
`an alphanumeric character string, or a strictly numerical value, for example a
`
`personal identification number (PIN) or password. In one embodiment, the user
`
`13
`
`
`
`data (P) is information uniquely associated with the user 110. The user data (P)
`
`can also be obtained by biometric measurement or observation.”).
`
`33.
`
`The combination function 230 combines input values using a variety
`
`of algorithms. For example, the combination function 230 can generate an
`
`authentication code by arithmetically adding inputs. Ex-1104, ’585 reference,
`
`[0058] (“user authentication device 120 generates an authentication code by
`
`arithmetically combining a secret stored by the user authentication device 120 and
`
`a user-supplied PIN”). In some embodiments, the combination function can use a
`
`one-way function1 to combine the input values. Ex-1104, ’585 reference, [0071]
`
`(“For example, in one simplistic embodiment, a one-way function such as a hash
`
`function, is applied to the values (K, T, E), and the result truncated to the right
`
`length, in order to arrive at a resulting authentication code.”). In still other
`
`embodiments, the combination function can generate an authentication code by
`
`“prepending or appending” inputs, or combining inputs “using a block cipher or
`
`other one-way function, or other algorithm, or a combination of these and other
`
`1 As the ’585 reference explains, a one-way function is “a mathematical function
`
`that maps a universe of input values to a universe of output values in such a way
`
`that knowledge of the output of the function does not allow one to reconstruct the
`
`input provided.” Ex-1104, ’585 reference, [0071].
`
`14
`
`
`
`techniques that combine two or more input values together.” Id., [0073].
`
`Prepending or appending can consist of concatenating bits that represent each of
`
`the various inputs together such that the end of a string of bits that represents one
`
`input is adjacent to the beginning of a string of bits that represents a second input.
`
`34. Once the authentication code is generated, it is generally transmitted
`
`to the verifier 105 to conduct a remote authentication. This remote authentication
`
`can also occur in multiple ways. In one embodiment, “the verifier 105 performs
`
`an algorithmic calculation on a received authentication code that ‘reverses’ some
`
`or all of an algorithmic calculation performed by the user authentication device
`
`120.” Ex-1104, ’585 reference, [0058]. In this example, the “verifier 105
`
`compares the result …to the value of the secret stored on the user's authentication
`
`device 120, or to the value that should have been generated at that time by the
`
`device 120 . . . . If they match, the user is authenticated. If they do not match, user
`
`authentication fails.” Id.
`
`35. The remote authentication can also be conducted in other ways. In
`
`one example, the authentication code is encrypted by the user authentication device
`
`and decrypted by the verifier 105. Id. (“In some embodiments the verifier 105
`
`decrypts a value encrypted by the user authentication device 120 using symmetric
`
`key encryption or asymmetric encryption techniques, such as public key
`
`encryption.”). In some examples, the verifier 105 calculates a series of
`
`15
`
`
`
`authentication codes depending on the possible authentication codes generated by
`
`the user authentication device 120. Id. (“In some embodiments, the verifier 105
`
`also calculates the authentication code with an input that indicates whether one or
`
`more events have occurred.”); id., [0050] (“In some embodiments, the verifier can
`
`determine authentication codes for a number of possible events and event states
`
`such that a number of authentication codes that can successfully authenticate the
`
`user 110 are possible . . . .”). In this example, the verifier 105 “compares the
`
`authentication information received over communications channel 170 and the
`
`authentication information generated by the verifier 105 to determine whether any
`
`match.” Id. (“In further embodiments, where a plurality of authentication codes
`
`that can successfully verify the user 110 are possible, the verifier 105 first
`
`determines an expected authentication code for an expected event state, and if the
`
`verifier receives a different authentication code, determines and compares
`
`authentication codes for other possible event states before indicating whether the
`
`authentication device has been successfully verified.”).
`
`36.
`
`Following a remote authentication attempt, the verifier “can
`
`communicate positive or negative acknowledgement…to the device 120 or directly
`
`to the user 110” to indicate a successful or failed authentication attempt. Ex-1104,
`
`’585 reference, [0050].
`
`The ’585 Reference Discloses An Authentication System For
`B.
`Financial Transactions
`
`16
`
`
`
`37. The ’585 reference discloses that authentication systems can provide
`
`access to financial services. Ex-1104, ’585 reference, [0039] (“Authentication can
`
`result in the performance of one or more actions including, without limitation,
`
`providing access or privileges, taking action, or enabling some combination of the
`
`two. Access includes, without limitation: access to a physical location,
`
`communications network, computer system, and so on; access to such services as
`
`financial services and records, health services and records and so on; or access to
`
`levels of information or services.”). The ’585 reference discloses that a successful
`
`authentication provided by the authentication system can be used to trigger access
`
`to various services including financial services, which includes a financial
`
`transaction such as a credit card transaction. I understand that Dr. Jakobsson
`
`testified that “financial services” would not include access to a financial
`
`transaction. Ex-2101, Jakobsson-Decl., ¶75; Ex-1117, Jakobsson-Dep., 103:3-
`
`112:14. I absolutely disagree with this interpretation of the ’585 reference. A
`
`POSITA would have understood that financial services include financial
`
`transactions such as the purchase of goods, and that a successful authentication
`
`using the system described in the ’585 reference could be used to grant access to a
`
`financial transaction.
`
`38. The ’585 reference discloses authentication techniques that can be
`
`applied to financial transactions such as credit card transactions and ATM
`
`17
`
`
`
`transactions. The ’585 reference also discloses that the user authentication device
`
`can itself be a credit card, which is clearly for a financial transaction. Ex-1104,
`
`’585 reference, [0041] (“In still other embodiments, a credit-card sized device 120
`
`is a card such as a credit card including a magnetic strip or other data store on one
`
`of its sides.”). Indeed, the only purpose of a credit card is for a financial
`
`transaction. Moreover, a POSITA would have understood how the authentication
`
`system of the ’585 reference could be applied to a credit card transaction because it
`
`provides an electronic authentication mechanism that could have been applied to
`
`many different applications including financial transactions such as a credit card
`
`transaction.
`
`C.
`
`The ’585 Reference Is Not Limited To One-Way Functions
`
`39. Dr. Jakobsson testified that the combination function “implicitly
`
`would involve something that is not invertible” (Ex-1117, Jakobsson-Dep.,
`
`125:18-23). He also testified that “not applying a one-way function would have
`
`been contrary to the goals of the inventors.” (Id., 134:19-135:7; Ex-2101,
`
`Jakobsson-Decl., ¶92) and that “all the examples given and the motivation of this
`
`requires that it’s a one-way function.” (Ex-1117, Jakobsson-Dep., 134:4-10.) Dr.
`
`Jakobsson has mischaracterized the reference.
`
`40. As discussed above, the ’585 reference discloses many examples of
`
`authentication techniques and a number of algorithms that can be used by the
`
`18
`
`
`
`combination function 230 to generate an authentication code. The ’585 reference
`
`does not require the use of one-way functions to create an authentication code and
`
`discloses examples that do not use one-way functions. For example, in [0058], the
`
`’585 reference discloses that the user authentication device 120 generates an
`
`authentication code by arithmetically combining a secret stored by the user
`
`authentication device 120 and a user-supplied PIN. When the verifier receives the
`
`authentication code described in [0058], the verifier decrypts the authentication
`
`code and then compares the result of the decryption with a stored secret to
`
`authenticate it. This example uses an encrypt-decrypt model where an
`
`authentication code is created, encrypted, sent to the verifier, decrypted and then
`
`verified (i.e., an “encrypt and decrypt” model). It does not involve any hash
`
`function or any other one-way functions. In contrast to the encrypt and decrypt
`
`model described in [0058], other examples in the ’585 reference disclose using a
`
`hash function to create an authentication code. These examples are different from
`
`the encrypt and decrypt model because an authentication code is created, processed
`
`using a hash function, and transmitted to the verifier, which creates its own
`
`authentication code. The verifier processes the authentication code it created using
`
`a hash function, and then compares the two hashed authentication codes to
`
`authenticate the user (i.e., a “hash and compare” model).
`
`19
`
`
`
`41.
`
`In other examples, the ’585 reference discloses the use of asymmetric
`
`encryption techniques to authenticate the user. ’585 reference at [0058] (“In some
`
`embodiments the verifier 105 decrypts a value encrypted by the user authentication
`
`device 120 using symmetric key encryption or asymmetric encryption techniques,
`
`such as public key encryption.”). A POSITA would have understood that the use
`
`of asymmetric encryption would obviate the need for use of one-way functions in
`
`the combination function. Use of a one-way function in a combination function
`
`serves to incorporate event states into a token emission in a cryptographically
`
`concealed form. Asymmetric encryption also accomplishes this goal. In fact, it
`
`provides stronger security than a one-way function, in the sense that it can achieve
`
`forward security, meaning that an adversary that compromises a token and learns
`
`its stored keys cannot determine the plaintext associated with an asymmetric
`
`ciphertext. In contrast, such an adversary can extract low-entropy data input to a
`
`one-way function, and indeed, in a setting where a one-way function alone is used,
`
`the adversary possesses knowledge equivalent to that of the verifier. A POSITA
`
`would therefore prefer use of asymmetric encryption where feasible. Asymmetric
`
`ciphertexts are longer than typical passcodes, and thus feasible only where wireless
`
`transmission of token data is supported. This is an option that the ‘585 reference
`
`explicitly teaches as a possible embodiment.
`
`20
`
`
`
`42.
`
`The ’585 reference discloses that the combination function can
`
`combine values using a one-way function “or other algorithm” (Ex-1104, ’585
`
`reference, [0073]), but Dr. Jakobsson testified that the phrase “or other algorithm”
`
`means “a one way function or a function with suitable functionality – which would
`
`be very hard to invert.” (Ex-1117, Jakobsson-Dep., 135:14-136:22).
`
`43. Dr. Jakobsson is mistaken. When the ’585 reference discloses that the
`
`combination function can be a “one-way function, or other algorithm,” (Ex-1104,
`
`’585 reference, [0073]), it means that the combination function can be an algorithm
`
`that is other than a one-way function. The ’585 reference does not require that the
`
`combination function perform a one-way function. The language of the ’585
`
`reference makes clear that the combination function can be any “other algorithm,
`
`or a combination of these and other techniques that combine two or more input
`
`values together.” Id. This means that the combination function can be as simple as
`
`prepending or appending inputs together to form an output authentication code.
`
`The ’585 reference never specifies that one-way functions are critical to the
`
`disclosure of the reference because one-way functions are not required.
`
`Contrary to Dr. Jakobsson’s Testimony, The ’585 Reference
`D.
`Discloses “Retrieving Or Receiving” Second Authentication
`Information.
`
`44. Dr. Jakobsson testified the verifier 105 “neither receive nor retrieves
`
`second authentication information” but instead “creates second authentication
`
`21
`
`
`
`information to which it compares the first authentication information. Ex-2101,
`
`Jakobsson-Decl., ¶54. I disagree for the reasons explained below. The verifier
`
`must receive or retrieve the second authentication code from some memory device
`
`to facilitate the comparison.
`
`45.
`
`The claims require a second device (i.e., a verifier) configured to
`
`“retrieve or receive” second authentication information. Ex-1101, ’826 patent,
`
`claims 1, 10, and 21. The ’585 reference discloses this limitation because, as
`
`discussed above, authentication codes can be authenticated by the verifier by
`
`generating a second authentication code (i.e., a “second authentication
`
`information”) at the verifier and comparing this second authentication code with
`
`the first authentication code generated by the user authentication device. When the
`
`verifier generates the second authentication code, it must store the s
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
