IPR2017-00338
`U.S. Patent No. 9,098,685
`
`Filed on behalf of EMC Corporation
`Docket No.: 0100157.00269US1
`
`By: Peter M. Dichiara, Reg. No. 38,005
`Arthur Shum, Reg. No. 74,973
`WILMER CUTLER PICKERING HALE AND DORR LLP
`peter.dichiara@wilmerhale.com
`arthur.shum@wilmerhale.com
`Tel.: 617-526-6466
`Fax: 617-526-5000
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`___________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________________________________________
`
`EMC CORPORATION
`Petitioner
`
`v.
`
`ACTIVIDENTITY, INC.
`Patent Owner
`
`Case IPR2017-00338
`U.S. Patent No. 9,098,685
`
`
`PETITIONER’S REPLY
`
`
`U.S. Patent No. 9,098,685
`
`Filed on behalf of EMC Corporation
`Docket No.: 0100157.00269US1
`
`By: Peter M. Dichiara, Reg. No. 38,005
`Arthur Shum, Reg. No. 74,973
`WILMER CUTLER PICKERING HALE AND DORR LLP
`peter.dichiara@wilmerhale.com
`arthur.shum@wilmerhale.com
`Tel.: 617-526-6466
`Fax: 617-526-5000
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`___________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________________________________________
`
`EMC CORPORATION
`Petitioner
`
`v.
`
`ACTIVIDENTITY, INC.
`Patent Owner
`
`Case IPR2017-00338
`U.S. Patent No. 9,098,685
`
`
`PETITIONER’S REPLY
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`
`TABLE OF CONTENTS
`
`
`Introduction .................................................................................................... 1
`I.
`II. Wood Anticipates the Challenged Claims ................................................... 2
`A. Wood discloses “determining a security policy . . . based on
`previously stored policy data and the received indication of
`[computing conditions]” ........................................................................ 2
`B. Wood discloses “registering the user identification data against stored
`user data” ............................................................................................. 13
`1. IV’s interpretation of “registering” is inconsistent with the claim
`and specification .................................................................................. 13
`2. Wood discloses the “registering” limitation under IV’s proposed
`construction. ........................................................................................ 16
`C. Wood discloses the limitations of claims 5 and 13 ............................. 19
`III. The Challenged Claims are Obvious over Wood in view of Neuman .... 22
`A. Neuman teaches “determining a security policy . . . based on
`previously stored policy data and the received indication” of
`computing conditions .......................................................................... 22
`It was Obvious to Combine Neuman with Wood ............................... 27
`
`B.
`
`i
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`
`I.
`
`INTRODUCTION
`IV’s Patent Owner Response (“POR”) repeats the same flawed arguments
`
`raised in its Preliminary Response (“POPR”), which the Board correctly rejected
`
`and should do so again now. IV repeats its contention that Wood (Ex-1011) and
`
`Neuman (Ex-1005) use a “fundamentally different” approach to determining a
`
`security policy than the ’685 patent (Ex-1001) — according to IV, one based solely
`
`on the information resource to be accessed, and not based on computing
`
`conditions.
`
`There is no dispute that Wood and Neuman consider the resource to be
`
`accessed in determining a security policy. But as the Board correctly explained in
`
`its Decision on Institution (“DI”), the determining step is “not exclusionary, i.e., it
`
`does not expressly preclude consideration of other parameters in addition to
`
`[computing conditions].” DI, 17; see also id., 26-27. The relevant question is
`
`whether Wood or Neuman consider the recited computing conditions claimed by
`
`the ’685 patent when determining a security policy. They plainly do. In fact,
`
`Wood and Neuman disclose identical security policies as those disclosed in the
`
`’685 patent, and they each “determine” a security policy based on the same inputs
`
`including the same recited computing conditions.
`
`IV’s arguments regarding other challenged limitations are similarly meritless
`
`and should be rejected.
`
`1
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`II. WOOD ANTICIPATES THE CHALLENGED CLAIMS
`As the Petition explains, Wood anticipates the ’685 patent. See, e.g., Pet.
`
`20-29, 33-54. IV focuses its challenges to Wood on three limitations. The Board
`
`correctly rejected IV’s arguments regarding these limitations in its institution
`
`decision, and should do so again. DI, 16-23.
`
`A. Wood discloses “determining a security policy . . . based on
`previously stored policy data and the received indication of
`[computing conditions]”
`IV attempts to paint Wood as using a “fundamentally different approach
`
`from the ’685 patent.” POR, 1. Specifically, IV claims that Wood “always
`
`determines a security policy based on the information resource being accessed.”
`
`Id., 18.1 And that “[i]t never determines a security policy based on ‘previously
`
`stored policy data’” and “the received indication of the type of communication link
`
`between the workstation and the security server, the geographic location of the
`
`workstation, or the time of access of the workstation” (id.) (hereinafter “computing
`
`conditions”).
`
`As an initial matter, the fact that Wood determines a security policy based in
`
`part on the information resource being accessed is irrelevant. As the Board
`
`recognized, the challenged claims are not exclusionary, and do not preclude the
`
`
`
` 1
`
` All emphasis added unless otherwise noted.
`
`2
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`consideration of other parameters. DI, 17. Indeed, the ’685 patent also discloses
`
`determining a security policy based on both computing conditions and the resource
`
`being accessed. See, e.g., ’685 patent, 7:23-30 (parameters include “the data being
`
`accessed…, the type of secured data being requested from the data server 19.…”);
`
`cl. 14 (security data identifies “data being accessed”); see also Goldschlag Dep.
`
`Tr., 66:8-15 (agreeing ’685 contains embodiments in which general accesses
`
`“secured data”); POPR, 8 (proposing a construction of “security policy” that
`
`includes a “request to access a resource”). Any criticism that Wood also
`
`determines a security policy based in part on the resource being accessed is thus
`
`misplaced.
`
`IV’s arguments that Wood uses a fundamentally different approach than the
`
`’685 patent, one which never determines a policy based on stored policy data and
`
`the recited computing conditions, are flatly inconsistent with Wood’s disclosures.
`
`As the Petition explains, Wood discloses the same examples of security policies,
`
`determined based on the same examples of stored policy data and the same
`
`computing conditions. Pet. 7, 15, 29, 35, 37. For example:
`
`3
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`Time: The ’685 patent discusses a security policy2 where attempts to access
`
`a resource between midnight and 6am are automatically denied. ’685 patent, 7:55-
`
`58 (see Pet. 7, 15, 29, 37). In this example, the time of a request (i.e., a recited
`
`computing condition) is compared against the policy-specified period of midnight
`
`to 6 am (i.e., as expressed by “previously stored policy data” 3). If the request falls
`
`within that period, a predetermined security policy applies which denies the
`
`request for access. If the request occurs at other times, a different predetermined
`
`security policy will apply. Ex-1040 (Goldschlag Dep. Tr.), 62:17-63:15.
`
`As the Petition explains, Wood discloses a substantively identical approach
`
`(Pet. 29, 37):
`
`
` 2
`
` In its POPR, IV argued “security policy” should mean “one or more rules to
`
`apply to a security relevant event such as a request to access a resource.” POPR,
`
`8-9. Dr. Goldschlag agreed IV’s proposed construction was within the broadest
`
`reasonable interpretation (BRI) of this term, Goldschlag Dep. Tr., 248:10-250:18,
`
`and agreed this example was properly within the BRI of “security policy.” Id.,
`
`35:14-36:16.
`
`3 As the Board recognized, “[p]olicy data may include multiple parameters” such
`
`as “the time, the day of the week.” DI, 18. See also Pet. 38-39; Neuman Decl.,
`
`¶88; POR, 4.
`
`4
`
`
`
`’685 Patent
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`Wood
`
`“For example, in accordance with the
`
`“For example, a given security policy
`
`security policy no access is to be
`
`and associated trust level mappings
`
`provided between midnight and 6:00
`
`may dictate a REFUSE response in
`
`am, the user requesting an access
`
`response to an access request to a
`
`during this period of time is
`
`sensitive resource (such as financial
`
`automatically denied access.”
`
`data) by any client entity…if the
`
`’685 patent, 7:55-58.
`
`
`
`access request is received over a dial-
`
`up line and originates from an
`
`unknown number or is received outside
`
`of working hours.” Wood, 9:59-67.
`
`Wood, like the ’685 patent, expressly discloses comparing the time of an
`
`access request (i.e., a recited computing condition) against a specified time period
`
`5
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`(i.e., “outside of working hours,” which is “previously stored policy data”4). If the
`
`request falls within that period, Wood, like the ’685 patent, applies a
`
`predetermined security policy which denies (REFUSE) the request for access. If
`
`the request occurs at other times, Wood, like the ’685 patent, will apply another
`
`predetermined security policy to the request.
`
`For example, Wood discloses a security policy that authorizes access based
`
`on trust levels. Wood explains that, if the current trust level of an access request
`
`meets or exceeds the required trust level for accessing the requested resource, then
`
`access is “ALLOWED” without further authentication needed. Wood, 9:50-52.
`
`Conversely, if the current trust level is too low, then the request may be
`
`“REDIRECTED” in which case Wood determines (e.g., selects) authentication
`
`schemes based on the user’s computing conditions or environment (e.g., time of
`
`access, location, and network) to permit the user to escalate its current trust level to
`
`
`
` 4
`
` A POSITA would understand that Wood’s security architecture includes pre-
`
`stored data, such as algorithms, parameters, and other data for implementing its
`
`process for determining a security policy. Pet. 38-39; Ex-1002 (Neuman Decl.),
`
`¶88; DI, 17-19.
`
`6
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`meet the required trust level.5 See, e.g., Wood, 10:13-21; Neuman Decl., ¶¶ 59-60;
`
`POR, 10-14; Ex-2007 (Goldschlag Decl.), ¶¶ 44-48; Goldschlag Dep. Tr., 144:17-
`
`145:13.
`
` IV argues that Wood determines a security policy based only on the
`
`information resource being accessed. POR, 18-21. According to IV, if the
`
`resource being accessed is not very sensitive, like archived data, Wood assigns a
`
`security policy that imposes only a low required trust level. See id., 19. If the
`
`resource is sensitive, like financial data, Wood applies a different security policy
`
`that requires a more substantial trust level. See id.
`
`
`
` 5
`
` This functionality in Wood is not disputed by IV. See, e.g., POR, 26-27. During
`
`his cross-examination, Dr. Goldschlag repeatedly characterized these passages in
`
`Wood as discussing a “process” for governing access to a resource, e.g., ALLOW
`
`or REFUSE access. See, e.g., Goldschlag Dep. Tr., 153:16-20; 155:7-10; 157:21-
`
`158:2; 162:3-14; 181:17-182:4. Ordinary dictionary definitions confirm that a
`
`“policy” is a “method of action”, i.e., process. See, e.g., Ex-1042 (Merriam-
`
`Webster Dictionary) (defining “policy” as, among other things, “a definite course
`
`or method of action selected from among alternatives and in light of given
`
`conditions to guide and determine present and future decisions.”).
`
`7
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`IV’s argument that the policy is determined solely on the resource is flatly
`
`inconsistent with both Wood’s disclosures and the ‘685 embodiments. Both the
`
`’685 patent and Wood determine a security policy based on the resource and on
`
`the computing condition of “time of access,” as well as on “previously stored
`
`policy data” that specifies the relevant time period for the policy. As Dr. Neuman
`
`explains, IV is wrong to suggest that Wood uses a fundamentally different
`
`approach than the ’685 patent; instead, he reiterates that Wood teaches
`
`“remarkably similar” policies, as its description of denying access “outside of
`
`working hours” functions the same way as the ’685 patent’s example of denying
`
`access between midnight and 6am. Neuman Decl. ¶67; Ex-1040 (Neuman Reply
`
`Decl.), ¶12.
`
`Location: The ’685 patent also describes security policies that are
`
`determined based on the location from which a request is made. See, e.g., ’685
`
`patent, 9:16-37 (discussed at Pet. 29); 9:55-62 (discussed at Pet. 7). Dr.
`
`Goldschlag focused on these location-based policies in his testimony, and created
`
`an example of a “security policy,” reproduced below, which is virtually identical to
`
`another Wood example (Pet. 29, 35, 37):
`
`
`
`8
`
`
`
`Goldschlag Dep., Ex-1039
`Goldschlag Example
`
`Wood
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`
`“Access is allowed from work by
`
`“In an exemplary enterprise tool
`
`employees”
`
`
`
`configuration, a desired security policy
`
`may dictate that a salary tool is
`
`Goldschlag Dep., Ex-1039; see also id.
`
`accessible only from with[in] a
`
`Tr., 29:3-22.
`
`
`
`
`
`company’s internal network. No level
`
`of authenticated trust may be sufficient
`
`to access such a tool from outside
`
`company network. To facilitate
`
`implementation of such a security
`
`policy, authorization component 140
`
`could refuse access based on
`
`environment parameters indicating a
`
`session originating outside the
`
`company’s internal network.” Wood,
`
`6:20-28.
`
`Wood expressly discloses a predetermined security policy determined by
`
`comparing the location of an access request (i.e., a computing condition) against
`
`9
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`specified location criteria (i.e., “within a company’s internal network,” expressed
`
`with “previously stored policy data”). If the request falls within that specified
`
`location, the policy permits access. This first security policy may impose
`
`additional requirements before access is permitted, e.g., by comparing a current
`
`trust level of the access request against a required trust level, as explained above.
`
`See Wood, 2:28-48; 9:26-46; 11:30-33; 14:8-25; POR, 10-14; Goldschlag Decl.,
`
`¶¶44-48. If the request occurs from outside the company network, a different
`
`security policy governs the request, which refuses access and in which “no level of
`
`authenticated trust may be sufficient.”
`
` Faced with this clear evidence about Wood, IV attempts to contort Wood’s
`
`use of trust levels. See generally POR, 18-27. IV contends that Wood’s security
`
`policies are based only on the minimum required trust level of the requested
`
`resource, id., 18, and that Wood uses “environment information” (i.e., computing
`
`conditions such as time, location, or type of communication link) only to determine
`
`the current trust level and not the required trust level. Id., 22-24, 26. Both
`
`arguments are demonstrably false.
`
`First, Wood’s location-based policy (like its time-based and other policies)
`
`is based on the information resource being accessed (i.e., a salary tool) and the
`
`computing condition of location (i.e., within a company’s internal network). Wood
`
`further explicitly states that “authorization component 140 may be programmed to
`
`10
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`perform some stringent testing beyond a trust level requirement” and “[n]o level
`
`of authenticated trust may be sufficient to access such a [salary] tool from outside
`
`company network.” Wood, 6:18-28. Accordingly, Wood’s location-based policy
`
`expressly refuses access regardless of trust levels, contradicting IV’s contention
`
`that Wood’s security policies are based only on the minimum required trust level
`
`of the requested resource. Neuman Reply Decl., ¶18-20.
`
`Second, Wood expressly teaches that environment information can be used
`
`to determine both the current trust level and the required trust level. Neuman
`
`Decl., ¶¶ 59-60, 87, 89, 92; Neuman Reply Decl., ¶21. Wood teaches that the
`
`required trust level (in addition to the current trust level) may vary based on
`
`computing conditions such as time, location, and type of communication link.6 As
`
`the Petition explains, Wood discloses that the required trust level for a resource
`
`may be determined “in the context of the requesting session environment.” Wood,
`
`
` 6
`
` Dr. Goldschlag agrees that Wood’s required trust levels are associated with
`
`security policies. See, e.g., Goldschlag Dep. Tr., 165:10-12 (“the required trust
`
`level…is the policy governing access to the resource”); see also 149:19-20;
`
`151:15-17; 159:10-11. This is consistent with the Petition’s analysis that changing
`
`the required trust level is another instance of determining security policy based on
`
`computing conditions. Pet. 37-39.
`
`11
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`14:48-51; Pet. 37-38; see also Wood, Abstract (“In some configurations, changing
`
`environmental parameters may cause a previously sufficient credential to become
`
`insufficient.”). Thus, Wood teaches that an information resource may have one
`
`required trust level under one set of computing conditions (i.e., environment) and a
`
`different required trust level under another set of computing conditions (i.e., a
`
`different environment). Therefore, when Wood teaches that a required trust level
`
`for accessing a resource may vary based on a “requesting session environment”,
`
`Wood again teaches determining a security policy based on computing conditions.
`
`Faced with this, IV makes the untenable claim that the term “environment”
`
`as used in column 14, lines 48-51 of Wood means something entirely different than
`
`what that term means throughout the rest of Wood (and the ’685 patent, for that
`
`matter). IV argues “environment” refers “to whether a session token is included in
`
`an information resource access request.” POR, 22-23. This strained interpretation
`
`of Wood should be rejected. To make this argument, IV attempts to rewrite
`
`Wood’s reference of “session environment” to “session token.” But Wood
`
`repeatedly uses the word “environment” to refer to the same things that the ’685
`
`patent calls “computing conditions,” and which the ’685 patent also calls
`
`“environment.” See, e.g., Wood, Abstract (“environmental parameters (e.g.,
`
`connection type or location)”); 2:66-67 (same); 6:32-34 (“environment
`
`information such as time of request, source of request, connection speed…”); 7:38-
`
`12
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`8:22 (listing “connect location”, “temporal information such as request time/date”,
`
`“origination point (e.g., inside or outside of a corporate network)” as examples of a
`
`“requesting client’s environment information.”); Goldschlag Dep. Tr., 109:14-
`
`110:14 (Dr. Goldschlag agreeing the ’685 patent also uses the word “environment”
`
`to refer to a received indication of a type of communication link, time of access,
`
`and geographical location.)
`
`In short, Wood and the ’685 patent disclose examples of “security policies”
`
`that are not only substantively identical, but are also determined based on the same
`
`“computing conditions” and “previously stored policy data.”
`
`B. Wood discloses “registering the user identification data against
`stored user data”
`IV premises its arguments that Wood fails to disclose the “registering”
`
`limitation on a strained, unsupportable reading of this limitation. The Board
`
`considered IV’s argument (see, e.g., POPR, 27-31), but did not construe the term
`
`(see, e.g., DI, 9; 19-20), consistent with the notion that “registering” does not carry
`
`any special meaning. Even so, the Board correctly recognized that Wood discloses
`
`this limitation even under IV’s proposed construction. DI, 20.
`
`1.
`
`IV’s interpretation of “registering” is inconsistent with the
`claim and specification
`IV does not dispute that Wood discloses comparing received user
`
`identification data (i.e. login credentials) against stored user data (i.e. pre-stored
`
`13
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`login credentials). POR, 27-37. Likewise, IV cannot seriously dispute that, during
`
`such authentication, Wood stores (i.e., registers) in its computers the received user
`
`identification (e.g., the received fingerprint or password) so that it may be
`
`compared against the pre-stored login credentials (i.e., “authorized” fingerprint
`
`data or password).7 See Goldschlag Dep. Tr., 125:6-14 (“[Q]: …with
`
`authorization, …the person presents some information, some claim, a fingerprint, a
`
`password, or whatever. And it’s compared against something to prove whether the
`
`person is who he or she claims to be, right? …[A]: Yes, that’s right…”); see also
`
`id., 128:11-16.
`
`There accordingly should be no dispute that Wood satisfies the registering
`
`step. For example, the fact that the recited registering operation is done “against
`
`previously stored user data” indicates that the BRI of the recited registering
`
`encompasses storing and comparing of “user data” against the “previously stored
`
`user data” that occurs in Wood’s authentication steps. As the Petition and Dr.
`
`
` 7
`
` IV and Dr. Goldschlag are wrong to suggest that some “authentication systems,
`
`do not generate a record of the received user identification data.” POR, 30;
`
`Goldschlag Decl., ¶88. Instead, as Dr. Neuman explains, the process of
`
`authenticating received login credentials would require “making a record” of the
`
`received login credentials so they may be verified. Neuman Reply Decl., ¶¶25-28.
`
`14
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`Neuman explain, Wood teaches that once a login credential has been supplied for
`
`authentication, that login credential is stored and compared against pre-stored login
`
`credentials. See, e.g., Pet. 44-45; Neuman Decl., ¶¶ 96-97; Wood, 12:13-15;
`
`12:32-36; Neuman Reply Decl., ¶29. If the received login credential matches with
`
`a pre-stored login credential, the former is authenticated, authorizing the access
`
`request.
`
`IV attempts to distort this plain meaning of registering by arguing that it
`
`means “make a record of the received user identification data,” and by demanding
`
`that this “registering” step must be distinct and separate from an “authentication”
`
`step and must precede authentication. POR, 28-31. There is no basis for this
`
`reading.
`
`First, IV’s interpretation blatantly attempts to read limitations into the claim.
`
`Nothing in the claim term “registering…against” demands an exclusion of the
`
`registering performed during authentication. Likewise, nothing in the claim term
`
`requires that this step must not only be separate and distinct from authentication
`
`but must precede it.
`
`IV cites a passage in the ’685 patent stating that “the security server
`
`performs an operation of registering the user data against previously stored user
`
`data in accordance with the determined at least an authorization method.
`
`Thereafter, the security server identifies the user and optionally authorizes the user
`
`15
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`to access secured data….” POR, 30-31 (citing 5:58-64). This passage simply
`
`parrots the claim language, falls far short of lexicography, and in no way demands
`
`the restrictions that IV injects into its interpretation. IV also points to the word
`
`“[t]hereafter,” POR, 31, but read in context, the passage supports Petitioner. It
`
`simply confirms that, as a consequence of the registering/authentication operation,
`
`the system can now properly identify the user (i.e., the purpose of authentication),
`
`and authorize the access if appropriate (i.e., optionally). In fact, this operation is
`
`depicted as a single step in FIG. 4 of the patent. This passage thus does not
`
`support IV’s argument.
`
`Second, IV does not even attempt to explain how one can “store” something
`
`“against” something else, further confirming its interpretation is wrong.
`
`Questioned about this point, Dr. Goldschlag testified that “registering user
`
`identification data against stored user data” means storing user identification data
`
`in a “database”—rewriting “against” to “in” and demanding “a database” even
`
`though he was unable to specifically identify such a database in the ’685 patent.
`
`Goldschlag Dep. Tr., 131:7-133:19; 136:10-15.
`
`Accordingly, IV’s interpretation of “registering” is unsupported, and
`
`improperly reads in limitations where none exist.
`
`2. Wood discloses the “registering” limitation under IV’s
`proposed construction.
`
`16
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`Moreover, Wood discloses this limitation even under IV’s proposed
`
`interpretation through its session credential structure and session token. See, e.g.,
`
`DI, 20.
`
`IV argues that Wood does not make such a record because Wood’s “session
`
`credential structure 420” and “session token 430” (illustrated in FIG. 4 of Wood,
`
`below) do not include the specific login credentials supplied by the user, such as
`
`received biometric data. POR, 33-35. However, the very figure that IV cites at
`
`page 34 of its POR (Wood at FIG. 4) shows that a “SessionCookie”, which IV
`
`does not dispute is “stored” by Wood’s system, includes a “principalID”.
`
`17
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`
`
`
`Wood, FIG. 4 (Annotated)
`As the Board previously recognized, there can be no dispute that
`
`“principalID” comprises “user identification data.” See, e.g., Wood, 19:51-53
`
`(“[p]rincipal id encodes an identifier for a principal to which the security
`
`architecture has resolved login credentials.”); (Ex. 2006) Neuman Dep. Tr., 77:20-
`
`25 (“Principal, that’s the identity, the entity that’s been authenticated….”); DI,
`
`20 (“Wood also explains that a principal identification (ID) may be encoded
`
`(stored) in a secured session credential.”). The principalID field includes data that
`
`18
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`is “received” as part of a user’s login credentials. See Wood, 18:40-42; 19:53-58.
`
`Principal ID is therefore an instance of “received user identification data,” which
`
`IV admits is stored as part of a record.
`
`Accordingly, as the Board recognized, Wood discloses the “registering”
`
`limitation even under IV’s flawed reading. See DI, 19-20.
`
`C. Wood discloses the limitations of claims 5 and 13
`Claims 5 and 13 require that “the security data further comprises data
`
`relating to available user data input devices for providing input to the workstation.”
`
`As the Petition explains, Wood discloses these limitations when it states that
`
`“capabilities of a particular client entity (e.g., … availability of a fingerprint
`
`scanner or card reader) may affect the availability or sufficiency of particular
`
`authentication schemes to achieve a desired trust level.” Pet. 52-53; Wood,
`
`Abstract; see also id., 2:67-3:4. Here, Wood plainly states it considers the
`
`“availability” of “user input devices” (e.g., fingerprint scanner or card reader) to
`
`determine whether certain authentication schemes are available and “sufficient” to
`
`satisfy a required trust level for a given access. Clearly, this information needs to
`
`be received as security data for Wood’s server to determine if a scheme is available
`
`or sufficient. Neuman Reply Decl., ¶35.
`
`IV complains that Wood’s disclosures are “vague” and “do not positively
`
`recite the usage of data relating to available user data input devices to ‘determine’
`
`19
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`an authorization method.” POR, 38-39. However, Wood need not “positively
`
`recite” a feature to disclose it. Instead, the issue is whether “a person of skill in the
`
`art, reading the reference, would ‘at once envisage’ the claimed arrangement or
`
`combination.” Microsoft Corp. v. Biscotti Inc., 878 F.3d 1052, 1068 (Fed. Cir.
`
`2017). See also In re Preda, 401 F.2d 825, 826 (CCPA 1968) (“[I]n considering the
`
`disclosure of a reference, it is proper to take into account not only specific
`
`teachings of the reference but also the inferences which one skilled in the art would
`
`reasonably be expected to draw therefrom.”).
`
`IV also attempts to distort Wood’s plain disclosure by arguing that “[i]f the
`
`client entity is not equipped with a biometric input device…, Wood’s system does
`
`not alter and/or select a different authentication scheme.” POR, 39. This is a clear
`
`misreading of Wood. Wood is explicit that it considers the availability of user
`
`devices to determine the sufficiency of an authentication scheme; in other words, it
`
`will only choose an authentication scheme that is available to the user and which
`
`would attain a “sufficient” current trust level to be permitted access to the resource.
`
`Neuman Reply Decl., ¶36.
`
`IV and Dr. Goldschlag further argue that “Wood offers the usage of multiple
`
`authentication schemes in the hopes that one or more of the schemes will be
`
`sufficient.” Id. Wood does not discuss such a (mere-hope) scheme anywhere in its
`
`specification. And as Dr. Goldschlag admitted in his deposition, it would have
`
`20
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`been unreasonable to interpret Wood to request a specific form of authentication
`
`(e.g., a password, biometric data, etc.) if it did not have stored credential
`
`information for the corresponding scheme. Goldschlag Dep. Tr., 227:4-228:10. A
`
`POSITA would therefore not have interpreted Wood to offer an authentication
`
`scheme merely in the “hope” that this scheme would be available and sufficient.
`
`Dr. Neuman explains that, contrary to IV’s unreasonable interpretation,
`
`Wood’s Abstract expressly teaches that its security server receives data relating to
`
`available user data input devices. First, Wood’s Abstract states that information
`
`regarding the availability of a fingerprint scanner or card reader affects the
`
`“availability or sufficiency of particular authentication schemes to achieve a
`
`desired trust level.” Wood’s security server thus decides what authentication
`
`schemes would be “available” and/or “sufficient” based on the “availability” of a
`
`fingerprint scanner or card reader. To make decisions based on this information,
`
`Wood’s security server must receive this information as data. And as the Petition
`
`explains for related independent limitation [1b], this information is received by the
`
`“entry handler functionality” in Wood’s “gatekeeper / entry handler component
`
`110,” which is responsible for receiving “environment information” including
`
`“client type and/or capabilities” and “system type.” Wood 7:47-49, 8:10-15, Pet.
`
`36. This corresponds to the “receiv[ed] security data” recited in claims 1, 5, and
`
`13. Neuman Reply Decl., ¶38. Second, as a matter of logic, the fact that Wood’s
`
`21
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`security server is offering a type of authentication scheme (e.g., fingerprints)
`
`means that Wood’s security server has a copy of data related to the acceptable
`
`fingerprint on file. And if Wood’s security server has an “official” fingerprint on
`
`file, this means the user had a fingerprint scanner available.
`
`III. THE CHALLENGED CLAIMS ARE OBVIOUS OVER WOOD IN
`VIEW OF NEUMAN
`IV raises similar complaints with Neuman as with Wood, arguing that
`
`Neuman selects a security policy based on the information resource accessed, not
`
`based on previously stored policy data and computing conditions. IV also claims
`
`that Petitioner has not shown sufficient motivation to combine Neuman and Wood.
`
`Again, the Board correctly rejected these arguments in its institution decision, and
`
`should do so again. DI, 26-27. Indeed, Neuman is abundantly explicit about
`
`determining security policies based on computing conditions, both disclosing a
`
`computer language and framework for doing so, and detailed examples.
`
`A. Neuman teaches “determining a security policy . . . based on
`previously stored policy data and the received indication” of
`computing conditions
`As the Petition explains and the Board recognized, Neuman is expressly
`
`directed at an access control framework capable of implementing multiple security
`
`policies. Pet. 31-33, 57; DI, 11. Neuman further explicitly discloses time-,
`
`location-, and connection-based security policies governing access to a resource.
`
`22
`
`
`
`IPR2017-00338
`U.S. Patent No. 9,098,685
`That Neuman also considers the information resource in determining a security
`
`policy is irrelevant. See DI, 17. All of IV’s arguments accordingly
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
