`
`
`
`
`
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`
`
`
`
`
`
` Paper 9
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_____________
`
`InAuth, Inc.,
`Petitioner,
`
`v.
`
`mSIGNIA, Inc.,
`Patent Owner
`_____________________
`
`Case IPR2018-00150
`U.S. Patent 9,559,852
`_____________________
`
`
`PATENT OWNER MSIGNIA INC.’S
`PRELIMINARY RESPONSE
`
`
`
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`TABLE OF CONTENTS
`
`I.
`
`II.
`
`INTRODUCTION ........................................................................................... 1
`
`PROCEDURAL BACKGROUND ................................................................. 3
`
`A.
`
`B.
`
`Procedural History ................................................................................. 3
`
`Co-Pending Litigation ........................................................................... 4
`
`III. CLAIM CONSTRUCTION ............................................................................ 4
`
`A.
`
`“generating a challenge” ....................................................................... 4
`
`IV. REASONS FOR NONINSTITUTION ........................................................... 5
`
`A.
`
`Etchegoyen ............................................................................................ 5
`
`1.
`
`2.
`
`3.
`
`4.
`
`Overview of Etchegoyen ............................................................. 5
`
`Etchegoyen does not disclose a system based on
`“anticipated changes to . . . stored data values.” ......................... 7
`
`Etchegoyen’s system does not store “anticipated
`changes to . . . stored data values.” ............................................. 9
`
`Dependent Claims ..................................................................... 11
`
`a.
`
`b.
`
`c.
`
`Etchegoyen does not disclose authentication
`based on “acceptable changes to a user
`minutia data value” (claims 4 and 5). ............................. 12
`
`Etchegoyen does not use the claimed “stored
`data value” to create the challenge (claim 7).................. 14
`
`Etchegoyen does not compare the response
`to member of a set of two or more allowable
`responses (claims 14-16). ............................................... 15
`
`5.
`
`are
`rationales
`combination
`stated
`InAuth’s
`inadequate. ................................................................................ 16
`
`i
`
`
`
`a.
`
`b.
`
`c.
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`InAuth’s motivation argument for claims 15
`and 16 is conclusory. ...................................................... 16
`
`InAuth’s combination argument for claims 6
`and 8-12 do not adequately explain how or
`why a POSA would have been motivated to
`overcome
`the
`significant
`differences
`between Etchegoyen and Jakobsson. .............................. 18
`
`InAuth’s combination argument for claims
`22 and 23 does explain how or why subject
`matter
`from Varghese would
`be
`incorporated into Etchegoyen. ........................................ 20
`
`B. Varghese .............................................................................................. 20
`
`1.
`
`2.
`
`3.
`
`Overview of Varghese .............................................................. 21
`
`Varghese’s system does not use “information
`regarding anticipated changes.” ................................................ 22
`
`make
`arguments
`Varghese
`InAuth’s
`determinations based on third-party information,
`and not based on data values from the “response.” .................. 23
`
`4.
`
`Dependent Claims ..................................................................... 25
`
`a.
`
`b.
`
`c.
`
`that Varghese
`InAuth has not shown
`provides a response having user minutia
`(claims 3-6). .................................................................... 25
`
`InAuth has not shown that Varghese uses a
`stored data value to generate a portion of the
`challenge (claim 7). ........................................................ 26
`
`InAuth has not shown the use of a “set of
`acceptable data values” (claims 8-12) or a
`“set of acceptable responses” (claims 14-
`16). .................................................................................. 27
`
`ii
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`InAuth has not shown that Varghese uses
`information from the response to update
`stored data values (claims 13, 22, and 23)...................... 28
`
`d.
`
`V.
`
`CONCLUSION .............................................................................................. 28
`
`iii
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`ActiveVideo Networks, Inc. v. Verizon Comm’ns, Inc.,
`694 F.3d 1312 (Fed. Cir. 2012) .......................................................................... 19
`
`NetMoneyIN, Inc. v. VeriSign, Inc.,
`545 F.3d. 1359 (Fed. Cir. 2008) ......................................................................... 26
`
`Unigene Labs., Inc. v. Apotex, Inc.,
`655 F.3d 1352 (Fed. Cir. 2011) .......................................................................... 17
`
`
`
`i
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`I.
`
`Introduction
`
`Authentication—the accurate recognition of devices and users—is a critical
`
`aspect of internet and e-commerce security. Unfortunately, basic
`
`username/password systems are widely recognized to be inadequate to address
`
`today’s security needs, due to the ease in hacking, stealing, or even guessing of
`
`passwords. Engineers have supplemented username/password protocols with a
`
`wide range of additional authentication technologies, such as requiring a user to
`
`answer additional security questions based on personal information, or using a
`
`hardware or software token. These methods are still susceptible to attack by
`
`hackers, however, and also create user “friction” by requiring the user to take
`
`additional steps; all this may irritate customers and prevent e-commerce
`
`transactions from succeeding.
`
`One way to provide additional security while minimizing friction is to create
`
`a digital “fingerprint” of a known device based on serial numbers and other data.
`
`Such fingerprints allow a system to recognize a returning device as authentic.
`
`However, because much of the data on devices is subject to change, it can be
`
`difficult to create a fingerprint that is both robust and persistent, particularly for
`
`mobile devices. Moreover, for many systems, the truly static data values (e.g.,
`
`CPU serial numbers) are either (a) unavailable due to privacy concerns or (b)
`
`easily spoofed.
`
`1
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`U.S. Patent No. 9,559,852 sought to address such concerns by creating a
`
`device fingerprinting system based on changing data. The system of the ’852
`
`patent uses information regarding anticipated changes to the fingerprint
`
`components of a device to determine whether the changes that occur are
`
`acceptable. By anticipating changes to fingerprint data values, mSIGNIA’s
`
`technology permits reduced-friction authentication without sacrificing security.
`
`This overcame the problems of prior art systems, which either had fingerprints that
`
`were too short-lived due to changing data, or had fingerprints that would accept
`
`any value because the system could not anticipate (i.e., expect, predict) how the
`
`data value would change.
`
`InAuth asserts that systems having this type of functionality were known in
`
`the prior art. InAuth first points to Etchegoyen (Exhibit 1004), a device
`
`fingerprinting patent that allegedly accepted changes according to whether they
`
`were “typical” or “non-typical.” As explained below, however, Etchegoyen’s
`
`system was completely incapable of anticipating a change to any of the data values
`
`at issue. Etchegoyen’s analysis only uses backwards-looking information about
`
`the changes after they occur to determine whether a threshold has been met.
`
`Indeed, Etchegoyen potentially accepts any and all changes to any and all data
`
`values; it can also reject any and all changes. This is not using anticipated changes
`
`2
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`to data values, because there is no anticipation as to when any value can be
`
`accepted or rejected.
`
`InAuth also alleges that Varghese (Exhibit 1005) renders the claims
`
`unpatentable. Varghese describes a system that tracks a device’s location and
`
`rejects changes that occur over an impossibly short time period. But this system
`
`(1) does not anticipate any changes; and (2) does not even look for acceptable
`
`changes. Instead, it merely rejects unacceptable changes, just like a
`
`username/password system or any other prior art authentication system. Even
`
`worse, after a set policy time, any location change becomes acceptable. Thus,
`
`Varghese’s authentication process also does not depend on information regarding
`
`anticipated changes as required by the claims, because it does not anticipate the
`
`changes to the data values.
`
`In short, InAuth has not carried its burden to show a reasonable likelihood
`
`that any of the challenged claims are invalid.
`
`II.
`
`Procedural background
`A.
`The ’852 patent issued on January 31, 2017 from an application filed March
`
`Procedural History
`
`18, 2016. It claims priority to a provisional patent application filed on February 3,
`
`2011. IA1009 (U.S. Provisional Patent Application No. 61/462,474). The ’852
`
`3
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`patent also claims priority via a chain of continuations to a non-provisional
`
`application filed on February 3, 2012. IA1001 at 2.
`
`B. Co-Pending Litigation
`The ’852 patent is the subject of litigation between mSIGNIA and InAuth.
`
`The case is styled mSIGNIA, Inc. v. InAuth, Inc., Case No. 8:17-01289, and is
`
`pending in the Central District of California. The parties have already begun
`
`discovery and have exchanged infringement contentions. Trial is scheduled for
`
`February 2019.
`
`III. Claim Construction
`The ’852 patent is subject to the broadest reasonable interpretation claim
`
`construction standard. mSIGNIA agrees with InAuth that, at least for purposes of
`
`the institution phase of the IPR, the claim language is adequately clear and that this
`
`IPR does not raise many issues requiring construction.
`
`“generating a challenge”
`
`A.
`InAuth has proposed that the term “generating a challenge” be construed as
`
`“generating a request for information.” Pet. at 13. mSIGNIA has no objection to
`
`this construction, but notes that the claimed “challenge” is a “challenge to the
`
`computer” being authenticated. ’852 patent, claim 1.e. Indeed, a main purpose of
`
`the invention of claim 1 is to “recognize that the presentation of identity
`
`information by a computer is authentic.” ’852 patent, claim 1.d. Thus, although
`
`4
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`mSIGNIA has no objection to InAuth’s proposed construction, it notes that the
`
`“request for information” must seek information from the computer being
`
`authenticated.
`
`IV. Reasons For Noninstitution
`A. Etchegoyen
`InAuth’s Etchegoyen-based challenges fail (1) because Etchegoyen does not
`
`teach the claim limitations regarding “anticipated changes”; (2) because
`
`Etchegoyen does not “store” the information that InAuth identifies as “anticipated
`
`changes”; and (3) because InAuth has failed to carry its burden on the dependent
`
`claims.
`
`1. Overview of Etchegoyen
`Etchegoyen describes fingerprinting a device by obtaining information from
`
`various device components and other attributes. Etchegoyen at 4:63-5:9. The
`
`device attributes used to create the finger print include components from a “typical
`
`upgrade list” such as “graphic card, random access memory, sound card, network
`
`adaptor, hard drive, CD/DVD drive, Ethernet controller, or other routinely
`
`upgraded components.” Id. at 5:4-6. The device fingerprint can also include
`
`portions based on “non-typical upgrade components” such as a “motherboard, USB
`
`host controller, central microprocessor, PCI Bus, System CMOS Clock, etc.” Id. at
`
`5:6-9. After a device creates a digital fingerprint, it registers the fingerprint with
`
`5
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`an authentication server, which stores the fingerprint. Id. at 5:19-21. Importantly,
`
`Etchegoyen does not claim that the authentication server registers or stores
`
`information about the components used to create the fingerprint or whether they
`
`are on the typical or non-typical upgrade lists; the authentication appears to store
`
`only the raw fingerprint data values, since it compare each later-received
`
`fingerprint to a plurality of stored fingerprints. See Etchegoyen at Abstract ((c));
`
`3:27-31, 5:26-31; 14:34-35.
`
`Etchegoyen uses the stored fingerprints on the authentication server to
`
`authenticate devices. Although Etchegoyen describes several methodologies, the
`
`Petition focuses on the authentication process of Etchegoyen Figure 4, which
`
`includes the following steps:
`
`First, a digital fingerprint having multiple “mini-fingerprints” is received by
`
`an authentication server. Id. at 12:19-20 (step 410). Each “mini-fingerprint”
`
`portion represents “a digital fingerprint of a component of the device.” Id. at
`
`12:23-24. Second, each individual portion of the received fingerprint is compared
`
`against the portions of a stored fingerprint. Id. at 12:29-31 (step 420). “[I]f a
`
`portion of the received digital fingerprint matches with any portions of a stored
`
`digital fingerprint, then a match of that portion is found.” Id. at 12:31-34. In
`
`contrast, any portions of the received fingerprint that do not a match are marked as
`
`having failed (step 430). Id. at 12:34-36. . If no match is found, then Etchegoyen
`
`6
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`decodes the received fingerprint portion to determine which component created it.
`
`Id. at 12:49-53 (step 440). The failed portions of the received fingerprint are then
`
`categorized according to whether that component was on the typical-upgrade or
`
`non-typical upgrade component list. Id. at 12:52-55.
`
`After categorizing each of the failed fingerprint portions, Etchegoyen totals
`
`each category, and compares the totals to a predetermined ratio (Step 450). Id. at
`
`13:22-38. For example, if the ratio is 1:1 (as it is in this embodiment of
`
`Etchegoyen), and there are more non-matched fingerprint portions from the
`
`typical-upgrade list than on the non-typical upgrade list, then Etchegoyen will
`
`authenticate the device (provided that other requirements are met). Id. at 13:25-26.
`
`In contrast, if there are more failed fingerprint portions from the non-typical
`
`upgrade list, then “chances are the device is a different device.” Id. at 13:28-33.
`
`2.
`
`Etchegoyen does not disclose a system based on “anticipated
`changes to . . . stored data values.”
`
`InAuth has failed to show that Etchegoyen’ system is based on “anticipated
`
`changes” to stored data values.
`
`The Petition’s “anticipated changes” arguments focus on Etchegoyen’s
`
`categorization of device components as “typical-upgrade components” and “non-
`
`typical-upgrade components.” However, these labels do not define the substance
`
`of what Etchegoyen actually does it its categorizations. Notably, Etchegoyen’s use
`
`7
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`of these categories does not describe “anticipated changes” to data values it stores.
`
`For example, Etchegoyen does not provide or rely on any prediction of how a
`
`given data value will change; whether a given data value will change; what the
`
`data value is expected to change to (e.g., the new serial number of a new graphics
`
`card); why the expected data value is expected to change, when the change is likely
`
`to occur, or how time will impact a data value. Indeed, the categorization does not
`
`provide or rely on information about the actual probability or even the general
`
`likelihood of a change occurring.
`
`At most, Etchegoyen asserts that upgrades to some types of components are
`
`typical, whereas upgrades to other components are non-typical. Etchegoyen at 5:4-
`
`9. But information regarding the relative typicality of a change occurring in two
`
`classes of data values does not make changes to those values “anticipated”; it just
`
`means that in Etchegoyen any change is possible. Moreover any change to any
`
`data value is permissible, so long as it is accompanied by a passing ratio of other
`
`changes. Similarly, Etchegoyen’s methodology would reject the identical change
`
`to a data value, if change were accompanied by a non-passing ratio of other
`
`changes. In fact, the same change could either be accepted or rejected depending
`
`on whether it was accompanied by other changes. Thus, Etchegoyen’s
`
`methodology does not rely on information regarding anticipated (i.e., predicted,
`
`foreseen, expected) changes to a specific data value; instead, Etchegoyen gives
`
`8
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`rules on what changes are acceptable to the group as a whole, but without actually
`
`anticipating any changes for any of the stored data values.
`
`In short, although the term “anticipated changes” is a broad concept that
`
`encompasses various types of information, Etchegoyen’s typical/non-typical
`
`categorization does not provide information regarding anticipated changes to
`
`Etchegoyen’s stored fingerprint data values.
`
`3.
`
`Etchegoyen’s system does not store “anticipated changes to .
`. . stored data values.”
`
`InAuth’s theory also falls apart on the requirement for both “stored . . . data
`
`values associated with the identity” and “stored . . . information regarding
`
`anticipated changes to one or more of the stored data values.”
`
`InAuth relies on the device fingerprint information as the stored data values,
`
`and on the typical/non-typical upgrade component list as the alleged “anticipated
`
`changes” to the stored data value. However, InAuth disregards the fact that
`
`Etchegoyen does not claim to store information about whether its fingerprints (or
`
`fingerprint portions) are on the typical or non-typical upgrade list. InAuth points
`
`to a passage in Etchegoyen asserting that the typical/non-typical component
`
`categorization is known when the device fingerprints are created (i.e., the “first
`
`boot fingerprint”). Etchegoyen at 4:63-5:2 (cited in InAuth’s Petition at 15). But
`
`once created, Etchegoyen does not claim to store information about whether a
`
`9
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`given fingerprint (or fingerprint portion) corresponds to a device on the typical
`
`upgrade or non-typical upgrade list. Etchegoyen also never attempts to
`
`recategorize its fingerprints/fingerprint portions as corresponding to a particular
`
`component on the typical or non-typical upgrade list. And InAuth never asserts or
`
`shows how this information is stored with the fingerprint. Pet. at 15-16, 19-20
`
`(element 1.c).
`
`Etchegoyen’s methodology confirms that it does not store information about
`
`whether a fingerprint portion corresponds to a typical or non-typical upgrade
`
`component; in fact, Etchegoyen does not link its stored fingerprint portions to any
`
`specific component at all. After the authentication server receives a new device
`
`fingerprint to authenticate, Etchegoyen’s method involves “comparing each portion
`
`of the received digital fingerprint with portions of a stored digital fingerprint. . . .
`
`[I]f a portion of the received digital fingerprint matches with any portions of a
`
`stored digital fingerprint, then a match of that portion is found.” Id. at 12:29-34.
`
`This methodology of identifying matches by comparing each received portion to
`
`multiple portions of the stored fingerprint would not be necessary if Etchegoyen’s
`
`stored fingerprint included the underlying component information. In such a case,
`
`Etchegoyen would simply do a one-to-one comparison for each of the
`
`10
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`corresponding portions of the stored and received fingerprint.1 The fact that
`
`Etchegoyen must separately decode and categorize the failed portions of the
`
`received fingerprint, Etchegoyen at 12:49-57, also confirms that it does not store
`
`any link between the stored fingerprint portions and the upgrade lists.
`
`Finally, InAuth points to the Etchegoyen’s “predetermined non-typical-
`
`upgrade component/typical upgrade component ratio” as being stored information
`
`regarding anticipated changes. Pet. at 16, 19-20 (element 1.c). However, this ratio
`
`only describes what to do with any and all changes that occur to the entire data set;
`
`it does not provide information regarding anticipated changes to any of the actual
`
`data values that make up Etchegoyen’s device fingerprint.
`
`Dependent Claims
`
`4.
`InAuth’s Etchegoyen-based arguments for the dependent claims also fail.
`
`
`1 In some embodiments, Etchegoyen stores the list of the components used to create
`
`the fingerprint. See, e.g., Etchegoyen at 3:31-34. These embodiments are
`
`irrelevant to this IPR, both because they are not cited in the Petition and because
`
`merely knowing the original component list does not correlate any specific
`
`component type with any specific fingerprint portion (data value), and thus cannot
`
`be used to recreate the typical/non-typical categorization of the original print.
`
`11
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`Etchegoyen does not disclose authentication based on
`“acceptable changes to a user minutia data value”
`(claims 4 and 5).
`
`a.
`
`Claims 4 and 5 require, among other things, a response that is based on “one
`
`or more acceptable changes to a user minutia data value.” Etchegoyen does not
`
`disclose this limitation.
`
`The ’852 patent relies on bits of “minutia” to distinguish between devices.
`
`In general, such minutia includes “any piece of information that can be definitively
`
`associated with the computer and its user.” ’852 patent at 6:27-37. In the
`
`framework of the ’852 patent, different types of minutia exist. For example,
`
`hardware minutia includes “items such as the device manufacturer, model number,
`
`serial number, [etc.].” Id. at 11:28-31. Similarly, software minutia includes values
`
`such as “application name, supplier information, memory reads, software
`
`cataloguing, clock and other counters, and date.” Id. at 11:35-38. Such software
`
`minutia values “often reflect customizations performed by the service user . . . .
`
`Significant customization affecting software minutiae values is typically done
`
`within days, even hours of ownership of a computer 18 by the service user 20.” Id.
`
`12
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`at 11:48-57. Thus, “user minutia” refers to changes and customizations made as a
`
`result of device usage (i.e., by the “user”).2
`
`Using this framework, Etchegoyen does not disclose authentication based on
`
`acceptable changes to a user minutia data value, as required by claims 4 and 5.
`
`Etchegoyen’s decision-making process focuses on hardware components from the
`
`typical and non-typical upgrade lists such as a graphic card, random access
`
`memory, sound card, network adaptor, motherboard, CPU, etc.3 Etchegoyen at
`
`5:2-9. The ’852 patent describes such components as containing “hardware
`
`minutia” data values. These components do not contain data values relevant to the
`
`user; they merely provide data values about the components themselves. Thus, the
`
`components on Etchegoyen’s upgrade lists cannot disclose the “one or more
`
`acceptable changes to a user minutia data value” limitations of claims 4 and 5.
`
`InAuth asserts that a hardware upgrade is a form of “user customization”
`
`recited in dependent claim 5. Pet. at 30. However, although a hardware upgrade is
`
`undoubtedly a “customization,” that does not somehow magically transform
`
`
`2 mSIGNIA does not believe a construction of “user minutia” is necessary here, but
`
`to the extent one is required, it should reflect these concepts.
`
`3 InAuth admits the sorts of components used in Etchegoyen do not contain any
`
`personally identifiable information. Pet. at 36.
`
`13
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`otherwise garden-variety hardware minutia into user minutia. The ’852 patent is
`
`very clear that the “user customization” discussed in the specification refers to user
`
`customization that makes the contents of the device specific to the user. See ’852
`
`patent at 11:55-61 (“Significant customization affecting software minutiae values
`
`is typically done within days, even hours, of ownership of a computer 18 by the
`
`service user 20. The software minutiae values diverge significantly at device
`
`personalization and the addressable space continues to expand throughout the use
`
`of the computer 18 by the service user 20.”) Thus, Etchegoyen’s hardware
`
`upgrades does not disclose a response based on “one or more acceptable changes to
`
`a user minutia data value” as required by claims 4 and 5 (emphasis added).
`
`b.
`
`Etchegoyen does not use the claimed “stored data
`value” to create the challenge (claim 7).
`
`Claim 7 requires that a “stored data value” (from claim 1) is used to create
`
`the challenge and that the determining operation comprises determining whether
`
`the stored data value and the corresponding data value in the response are the
`
`same. Etchegoyen does not do this.
`
`Etchegoyen describes a “request code” that requests “another digital
`
`fingerprint using information from the same components used to generate the first
`
`boot fingerprint.” Etchegoyen at 11:19-22 (cited by Pet. at 31). Subsequently,
`
`Etchegoyen compares each portion of the received fingerprint with the stored
`
`14
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`fingerprint portions, looking for a match. According to the Petition, this process
`
`invalidates claim 7 because the list of components is the claimed “stored data
`
`value,” and Etchegoyen’s matching process meets the other claim elements.
`
`InAuth is correct that Etchegoyen can use a list of component types to create
`
`a request code. But in InAuth’s theory, the list of attributes used to create the
`
`fingerprint is not the claimed “stored data value.” Instead, InAuth’s theory for
`
`claim 1 identifies Etchegoyen’s fingerprints as the stored data value, and not the
`
`list of components used to make the fingerprint. Moreover, even assuming that
`
`this list of component types were the claimed “stored data value,” InAuth’s theory
`
`would run into even more problems. Etchegoyen does not disclose storing
`
`anticipated changes to the list of components used to create the fingerprint, which
`
`would also be required under InAuth’s claim 7 theory. Thus, InAuth has not
`
`shown that Etchegoyen discloses all elements of claim 7.
`
`c.
`
`Etchegoyen does not compare the response to member
`of a set of two or more allowable responses (claims 14-
`16).
`
`Claims 14-16 each require comparison of the response to a member of a set
`
`of two or more allowable responses (claim 14).
`
`InAuth asserts that in Etchegoyen, the set of two responses includes (1) a
`
`previously stored fingerprint; and (2) a partial mismatch that satisfies the upgrade
`
`ratio. Pet. at 32-33. However, Etchegoyen does not compare the response to any
`
`15
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`so-called “partial mismatch.” To the contrary, the only “partial mismatch” used in
`
`Etchegoyen is the response itself. Etchegoyen at 12:28-38. Thus, InAuth has not
`
`identified comparing the response to a “set of two or more allowable responses.”
`
`InAuth’s arguments for claims 15-16 fail for additional reasons. Claim 15
`
`further requires the set of allowable responses to be computed prior to the
`
`determining step. InAuth’s argument fails because it relies on the alleged “partial
`
`mismatch,” which is created as part of Etchegoyen’s matching process, and not
`
`before. Claim 16 requires the set of allowable responses to be computed
`
`concurrently with the determining operation. However, InAuth relies on the
`
`previously-stored fingerprint which, by definition, is stored, not computed
`
`concurrently with the determining step as required by the claim language. Thus,
`
`InAuth has not carried its burden for claims 15-16.
`
`InAuth’s stated combination rationales are inadequate.
`
`5.
`Many of InAuth’s stated combination rationales are also inadequate.
`
`a.
`
`InAuth’s motivation argument for claims 15 and 16 is
`conclusory.
`
`InAuth’s motivation to combine argument for claims 15 and 16 fails because
`
`it is conclusory. Claim 15 requires the allowable response to be computed at
`
`particular times. InAuth argues, in essence, that varying the times when an
`
`allowable response is computed are “simply design options” that would have been
`
`16
`
`
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`
`obvious to a POSA. Pet. at 38. However, InAuth provides no analysis of the
`
`nature of these options, their impact on the overall system, or anything else to
`
`prove that its assertion is true, aside from the testimony of its expert which is
`
`equally conclusory. Ex. 1003, ¶ 154. Moreover, simply being a “design option”
`
`does not give a POSA a reason to select and follow that option in the ordinary
`
`course. Unigene Labs., Inc. v. Apotex, Inc., 655 F.3d 1352, 1360 (Fed. Cir. 2011)
`
`(“Obviousness requires more than a mere showing that the prior art includes
`
`separate references covering each separate limitation in a claim under examination.
`
`Rather, obviousness requires the additional showing that a person of ordinary skill
`
`at the time of the invention would have selected and combined those prior art
`
`elements in the normal course of research and development to yield the claimed
`
`invention.”)
`
`InAuth’s expert also makes the argument that there are different costs and
`
`different benefits to computing the set of responses at different times. However,
`
`this section of his report was not cited in the Petition and cannot supplant the
`
`arguments that InAuth actually made. Compare Pet. at 38 with Ex. 1003, ¶ 155.
`
`Moreover, to the extent that there are notable differences in the costs and benefits
`
`of each option, then this is inconsistent with InAuth’s “simple design options”
`
`argument.
`
`17
`
`
`
`b.
`
`Patent Owner’s Preliminary Response
`Case No. IPR2018-00150/US Patent No. 9,559,852
`
`InAuth’s combination argument for claims 6 and 8-12
`do not adequately explain how or why a POSA would
`have been motivated to overcome the significant
`differences between Etchegoyen and Jakobsson.
`
`InAuth’s obviousness arguments for claims 6 and 8-12 attempt to combine
`
`Etchegoyen with certain teachings from Jakobsson, a patent on authentication
`
`through user behavior tracking (e.g., being in a known location, calling a known
`
`telephone number). Pet. at 39-43.
`
`InAuth asserts that a POSA would have combined Etchegoyen with
`
`Jakobsson to “gain the benefit of expanding the types of minutia that can be used
`
`in the Etchegoyen system” and to “add further layers of specificity and security to
`
`the system.” Pet. at 41. InAuth also asserts that adding the minutia values of
`
`Jakobsson would “constitute mere substitution of components, each operating in
`
`their customary and expected manner.” Pet. at 41. InAuth further asserts that
`
`Etchegoyen “is already designed to make the types of comparisons and
`
`determinations disclosed by Jakobsson.” Id. (emphasis in original)
`
`InAuth has not carried its burden. Alth
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
