`Tel: 571-272-7822
`
`
`
`
`Paper 45
`Entered: July 2, 2018
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`EMC CORPORATION,
`Petitioner,
`
`v.
`
`ACTIVIDENTITY, INC.,
`Patent Owner, and
`
`INTELLECTUAL VENTURES I LLC,
`Exclusive Licensee.1
`____________
`
`Case IPR2017-00338
`Patent 9,098,685 B2
`____________
`
`
`Before JAMES B. ARPIN, LYNNE E. PETTIGREW, and
`KEVIN C. TROCK, Administrative Patent Judges.
`
`TROCK, Administrative Patent Judge.
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and
`37 C.F.R. § 42.73
`
`
`1 Paper 13, 2–3; Paper 18, 1–2; Paper 19; see Paper 6, 1 (“The real parties-
`in-interest are ActiviDentity, Inc. and Intellectual Ventures I LLC.
`ActiviDentity, Inc. is the owner of U.S. Patent No. 9,098,685 (‘the ’685
`patent’). Intellectual Ventures I LLC is the exclusive licensee of the ’685
`patent and has the sole and exclusive right and obligation to select and retain
`counsel to defend the ’685 patent.”).
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`
`
`I. INTRODUCTION
`
`EMC Corporation, (“Petitioner”) filed a request for inter partes
`review of claims 1, 3, 5, 7–9, 11, 13, 15, 16, and 19 (the “challenged
`claims”) of U.S. Patent No. 9,098,685 B2 (Ex. 1001, “the ’685 patent”).
`Paper 1 (“Pet.”). Intellectual Ventures I LLC (“Exclusive Licensee”) filed a
`Preliminary Response. Paper 8 (“Prelim. Resp.”). We instituted an inter
`partes review of all of the challenged claims on all of the asserted grounds.
`Paper 9 (“Dec. Inst.”).
`Exclusive Licensee filed a Response (Paper 24, “Resp.”) and
`Petitioner filed a Reply (Paper 29, “Reply”). A hearing was held on April 9,
`2018, a transcript of which has been entered into the record (Paper 43,
`“Tr.”).
`We have jurisdiction under 35 U.S.C. § 6(b). This Final Written
`Decision is issued pursuant to 35 U.S.C. § 318(a). We base our decision on
`the preponderance of the evidence. 35 U.S.C. § 316(e); 37 C.F.R. § 42.1(d).
`Having reviewed the arguments of the parties and the supporting evidence,
`we find that Petitioner has demonstrated by a preponderance of the evidence
`that each of the challenged claims is unpatentable.
`
`A. The ’685 Patent
`
`The ’685 patent (the “Specification”) describes methods of
`authorizing a user to access a workstation or secured data. Ex. 1001, 1:13–
`19, 2:64–3:2. The Specification recognizes that security systems based on
`pre-set codes, passwords, biometric identification, and “predetermined
`combinations” of these measures were known in the art. Id. at 1:22–53,
`
`2
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`2:48–50. The Specification also acknowledges that organizations included
`additional security processes for remote access to their sites. Id. at 2:54–63.
`The Specification describes an approach to authorization that varies based
`on “computing conditions,” including: (1) the type of communication link,
`(2) the geographical location of the workstation, and/or (3) the time of
`access. According to the Specification, a “security policy” is determined
`from a set of predetermined security policies based on previously stored
`policy data and computing conditions. An authorization method then is
`determined from this security policy and the computing conditions. Id. at
`claim 1, 3:19–34, 5:55–6:2.
`Figure 3A of the Specification illustrates relevant system components.
`
`In Figure 3A, shown above, workstation 10 is connected to security
`server 13 though communication link 15. Id. at 5:18–22. Security server 13
`stores policy data and also controls access to secured data on data server 19.
`Workstation 10 also is connected to user data input device 14 (e.g., smart
`
`
`
`3
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`card reader or a biometric sampling device), and to keyboard 12. Id. at
`5:22–28.
`A user requesting access to secured data stored in data server 19
`provides user information (e.g., a password or fingerprint scan) to user input
`device 14 of workstation 10, which forwards this user information to
`security server 13. Id. at 5:46–54, 7:35–46, 6:63–65. Workstation 10 also
`provides security server 13 with “workstation data” (also referred to as
`“computing conditions”), such as “the geographical location of the
`workstation, the time the request for access is being performed, the type of
`the request, and so forth.” Id. at 7:43–46; see also id. at 6:3–4.
`The security server determines the applicable security policy based on
`previously stored policy data and “computing conditions,” such as the type
`of user data input device, the geographic location of the workstation, the
`type of communication link between the workstation and the security server,
`user ID, the data being accessed, the type of secured data being requested
`from the data server, and the country. Id. at 5:64–6:2, 6:29–33, 7:17–30.
`The security server also determines an authorization method (id. at
`5:55–58) from the determined security policy and the computing conditions
`(id. at 5:64–6:2). The Specification describes several examples of
`authorization methods, including methods that use a “smart card reader” (id.
`at 5:24–27), a “biometric sampling device such as a fingerprint imager, a
`voice recognition system, a retinal imager or the like” (id.), “password[s]”
`(id. at 4:63–65), and “card based user authentication” (id.; see also id. at
`6:49–65).
`The security server uses the determined authorization method to
`authorize the user’s request to access the protected resource. This involves
`
`4
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`receiving user identification data (e.g., a password or fingerprint) (id. at
`6:63–65) and comparing the user identification data with previously stored
`user data (e.g., a previously stored password or fingerprint corresponding to
`an authorized user) (id. at 5:57–61). The specific type of user identification
`data that the security server requests and compares will depend on the
`determined authorization method. Id. at 6:40–54. If the received user
`identification data matches the previously stored user data, the security
`server identifies the user and can authorize the user to access secured data.
`Id. at 5:61–63.
`
`B. Challenged Claims
`
`Petitioner challenges claims 1, 3, 5, 7–9, 11, 13, 15, 16, and 19 of the
`’685 patent. Challenged claims 1, 9, and 19 are independent. Claim 1 is
`illustrative and is reproduced below.
`1. A method of authorizing a user to access a workstation using
`a security server, the method comprising:
`
`receiving security data relating to computing conditions in
`which an authorization will be performed, wherein the security
`data comprises at least one indication of a type of communication
`link between the workstation and the security server, a
`geographic location of the workstation, or a time of access of the
`workstation;
`
`determining a security policy from a plurality of
`predetermined security policies 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;
`
`determining an authorization method for authorizing the
`user, wherein the authorization method is determined from the
`determined security policy in accordance with the received
`indication of the type of communication link between the
`
`5
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`
`workstation and the security server, the geographic location of
`the workstation, or the time of access of the workstation;
`
`receiving user identification data; and
`
`registering the user identification data against stored user
`data in accordance with the determined authorization method,
`wherein different authorization methods for authorizing the user
`are determined upon receipt of different security data, and
`wherein the security data does not include identification
`information for a particular user.
`Ex. 1001, 10:27–55.
`
`A. Claim Construction
`
`II. DISCUSSION
`
`In an inter partes review, claim terms in an unexpired patent are given
`their broadest reasonable construction in light of the specification of the
`patent. 37 C.F.R. § 42.100(b). Consistent with that standard, we assign
`claim terms their ordinary and customary meaning, as would be understood
`by one of ordinary skill in the art at the time of the invention, in the context
`of the entire patent disclosure. See In re Translogic Tech., Inc., 504 F.3d
`1249, 1257 (Fed. Cir. 2007). Only those terms that are in controversy need
`be construed, and only to the extent necessary to resolve the controversy.
`See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir.
`1999).
`
`1. “security policy”
`
`Petitioner argues that the broadest reasonable interpretation of
`“security policy” in the context of the ’685 patent is “rules specifying
`conditions for accessing a secure resource.” Pet. 15 (quoting Ex. 1002 ¶ 41).
`Petitioner’s declarant, Dr. B. Clifford Neuman, testifies that the ’685 patent
`
`6
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`“describes a ‘security policy’ consistent with the ordinary meaning of the
`term, as something that ‘determin[es]…at least an authorization method for
`the user.’” Ex. 1002 ¶ 42 (citing Ex. 1001, 5:64–6:2, 7:50–54).
`In its Response, Exclusive Licensee argues that construction of the
`term “security policy” is not necessary and does not propose a construction
`for the term. Resp. 6. At oral argument, however, Exclusive Licensee’s
`counsel agreed that a security policy is essentially a set of rules to apply.
`See Tr. 18:3–7.
`The ’685 patent does not define expressly the term “security policy.”
`Petitioner’s proffered construction, that a “security policy” is “rules
`specifying conditions for accessing a secure resource,” is generally
`consistent with the use of the term in the Specification, including the claims.
`For example, the Specification explains “[i]n dependence upon the security
`policy . . . an authorization method . . . is selected.” Ex. 1001, 7:50–54. The
`Specification also explains, “the authorization method is varied because a
`security policy . . . is different.” Id. at 6:3–7. The Specification provides
`some examples of the parameters or conditions that a security policy
`considers. For instance, a security policy may consider the requested time of
`access, and may indicate that no access is provided between the hours of
`midnight and 6:00 a.m. Ex. 1001, 7:55–58. The Specification indicates that
`a security policy may vary based on the location of the user requesting
`access. Id. at 9:55–62. The Specification also indicates a security policy
`may require the use of different user authentication devices. Id. at 8:23–45,
`9:8–15, 9:28–37; Ex. 1002 ¶ 42.
`
`7
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`
`Therefore, we determine that the broadest reasonable interpretation of
`the claim term “security policy” consistent with its use in the ’685 patent is
`“a rule or set of rules specifying conditions for accessing a secure resource.”
`
`2. “authorization method”
`
`Petitioner argues the broadest reasonable interpretation of an
`“authorization method,” in the context of the Specification, is a “method of
`identifying and/or authorizing a user to access a resource.” Pet. 16 (quoting
`Ex. 1002 ¶ 43).
`Exclusive Licensee argues that construction of the term “authorization
`method” is not necessary and does not propose a construction for the term.
`Resp. 6.
`The ’685 patent does not define expressly the term “authorization
`method.” Nevertheless, Petitioner’s proffered construction, that an
`“authorization method” is a “method of identifying and/or authorizing a user
`to access a resource,” is generally consistent with the use of the term in the
`Specification. For example, the ’685 patent explains that “[i]n the
`authorization method, the user is first identified with the security server and
`then optionally authorized thereby.” Ex. 1001, Abstract. The Specification
`also explains how to determine “an authorization method to perform at least
`one of identifying and authorizing the user.” Id. at 6:42–45. The
`Specification describes various methods for identifying and authenticating
`users, including “a smart card reader” (id. at 5:24–27), a “biometric
`sampling device such as a fingerprint imager, a voice recognition system, a
`retinal imager or the like” (id.), “password[s]” (id. at 4:63–65), and “card
`based user authentication” (id.). See also id. at 6:49–65; Ex. 1002 ¶ 44.
`
`8
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`
`Therefore, we determine the broadest reasonable interpretation of the
`claim term “authorization method” consistent with its use in the ’685 patent
`is “a method of identifying and/or authorizing a user to access a computer or
`network resource.”
`
`B. Level of Ordinary Skill in the Art
`
`Petitioner argues that, at the time the ’685 patent was filed, a person
`of ordinary skill in this art would have had at least a bachelor’s degree in
`computer science or electrical engineering and 3–5 years of professional
`experience in computer systems security, or a master’s or doctorate and 1–2
`years of professional experience in computer systems security, or equivalent
`academic experience. Pet. 4. Petitioner argues such a person would have
`been familiar with designing and implementing computer systems security,
`and would have been aware of design trends relating to selecting and
`applying security policies, and methods of authenticating and authorizing
`users. Id. (citing Ex. 1002 ¶ 20).
`Exclusive Licensee’s Response does not appear to identify or provide
`any assessment of the level of skill possessed by an ordinary artisan in the
`field of the claimed invention at the time of filing. Exclusive Licensee’s
`declarant, Dr. David Goldschlag, however, testifies that a person of ordinary
`skill in the art would have had a bachelor’s degree in electrical engineering,
`computer engineering, computer science, or equivalent field with three or
`four years of academic or industry experience in communications. This
`assessment would include a person with a master’s degree in the
`aforementioned fields with coursework in computer network security and
`one or two years of experience in communications. Ex. 2007 ¶ 20.
`
`9
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`
`We find that a person of ordinary skill in the art in the field of the
`’685 patent is a person who has a bachelor’s degree in computer science,
`computer engineering, electrical engineering, or equivalent field and 3–4
`years of professional or academic experience in computer systems, network
`security, or network communications, or a master’s or doctorate degree and
`1–2 years of professional experience in computer systems, network security,
`or network communications, or equivalent academic experience.
`
`C. Prior Art References and Alleged Grounds of Unpatentability
`
`Petitioner relies upon the following prior art references:
`
`(1) U.S. Patent No. 6,691,232 (“Wood”) (Ex. 1011); and
`(2) Access Control Framework for Distributed Applications, Jun. 23,
`1999 (“Neuman IETF”) (Ex. 1005).
`Petitioner asserts the following grounds of unpatentability for all of
`the challenged claims:
`(1) The challenged claims are unpatentable under 35 U.S.C. § 102(a)
`and § 102(e) as anticipated by Wood. Pet. 33–53.
`(2) The challenged claims are unpatentable under 35 U.S.C. § 103(a)
`as obvious over the combination of Wood and Neuman IETF. Id. at 54–66.
`
`D. Overview of Prior Art References
`1. Wood (Ex. 1011)
`
`Wood is directed to a security architecture with environment sensitive
`credential sufficiency evaluation. Ex. 1011, Title. Wood discloses using
`environment information in a security policy, and describes a security
`architecture that allows temporal, locational, connection type and/or client
`capabilities-related information to affect the sufficiency of a given credential
`
`10
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`type (and associated authentication scheme) for access to a particular
`information resource. Id. at Abstract. In some configurations, Wood
`explains, environment information, such as time of access, originating
`location (physical or network) and/or connection type, forms a risk profile
`that may be factored into credential type sufficiency. Id. In some
`configurations, changing environmental parameters may cause a previously
`sufficient credential to be deemed insufficient. Id.
`Alternatively, Wood explains, an authenticated credential previously
`insufficient for access at a given trust level may be deemed sufficient based
`on a changed or more fully parameterized session environment. Id. In some
`configurations, the use of session tracking facilities (e.g., the information
`content of session tokens) may be tailored to environmental parameters (e.g.,
`connection type or location). Id. Similarly, Wood explains, capabilities of a
`particular client entity (e.g., browser support for 128-bit cipher or
`availability of a fingerprint scanner or card reader) may affect the
`availability or sufficiency of particular authentication schemes to achieve a
`desired trust level. Id.
`Wood’s security system is depicted, for example, in Figure 1
`(including Petitioner’s annotations) below.
`
`11
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`
`
`
`Pet. 21.
`Annotated Figure 1 depicts client application 170, in this instance a
`browser operated by a user, which communicates with a security architecture
`(blue) that governs access to information resources 190–193 (green).
`Ex. 1011, 5:13–23. The security architecture here includes gateway
`keeper/entry handler component 110, login component 120 (orange),
`authentication component 130, authorization component 140, identification
`component 150, and session management component 160. Id. at 5:13–29.
`Gatekeeper/entry handler component 110 allows, redirects, or refuses access
`requests in accordance with a security policy. Id.
`
`12
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`
`2. Neuman IETF (Ex. 1005)
`
`Neuman IETF is a paper authored by Dr. B. Clifford Neuman2 and Dr.
`Tatyana Ryutov, dated June 23, 1999, and provided to the Internet
`Engineering Task Force. Ex. 1005, 1. Neuman IETF describes a unified
`model to support authorization in a wide range of applications. Id. Neuman
`IETF explains that the authors’ model provides a “flexible and expressive
`mechanism for representing and evaluating security policies,” and is
`“capable of implementing a number of different security policies, based on
`diverse authorization models, which can coexist in distributed systems.” Id.
`at 1, 3. The authorization framework described in Neuman IETF “supports
`various strengths of user authentication mechanisms” and may identify the
`same principal “using different authentication methods.” Id. at 18.
`Neuman IETF explains that conditions may specify different “type-
`specific policies under which an operation can be performed on an object.”
`Id. at 8. Examples of such conditions may include “connection” (e.g.,
`“security of the connection”), “location” (“[l]ocation of the principal” such
`that “[a]uthorization is granted to the principals residing in specific hosts or
`domains”), and “time” (“[t]ime periods for which access is granted, e.g. time
`of day or day of the week”). Id.
`
`E. Anticipation of Challenged Claims
`
`Petitioner contends that claims 1, 3, 5, 7–9, 11, 13, 15, 16, and 19 are
`anticipated by Wood. Pet. 33–52.
`
`
`2 Dr. Newman also is Petitioner’s declarant. See Ex. 1002 ¶ 68.
`
`13
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`
`1. Anticipation of Independent Claim 1
`a. “A method of authorizing . . . using a security server”
`
`The preamble of claim 1 recites “[a] method of authorizing a user to
`access a workstation using a security server.” Ex. 1001, claim 1. With
`respect to the preamble, Petitioner relies on Wood’s description of
`authorizing access to information resources such as an “order processing
`system” (Ex. 1011, 5:38–39) and a “salary tool” (Ex. 1011, 6:22). Pet. 34–
`35. Petitioner argues that each of these information resources may be
`considered a “workstation.” Id. Petitioner also argues that Wood’s client
`application 170 would qualify as a “workstation” because a person of skill in
`the art would appreciate that this client application executes on an end user
`terminal. Id. at 35 (citing Ex. 1002 ¶ 81). Petitioner further argues that a
`person of ordinary skill in the art would have understood that at least some
`of the components of the security architecture described in Wood (e.g.,
`gatekeeper/entry handler component 110, authentication component 130,
`etc.) constitute a “security server.” Id. (citing Ex. 1011, 5:13–29, 20:50–53;
`Ex. 1002 ¶ 82).
`Exclusive Licensee does not contest Petitioner’s evidence or
`arguments with respect to the preamble. See Resp. 7–31.
`We find, on the basis of the evidence and explanation provided by
`Petitioner, that Wood’s description of a process that uses security
`architecture for authorizing access to information resources, such as an order
`processing system, a salary tool, or other similar client application, discloses
`the recited “method of authorizing a user to access a workstation using a
`security server” of claim 1.
`
`14
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`
`b. “receiving security data relating to computing
`conditions . . . of the workstation”
`For this limitation, Petitioner relies on Wood’s description that “entry
`handler functionality” in gatekeeper/entry handler component 110 receives
`“environment information” including type of communication link, location,
`and request time. Pet. 35–36; Ex. 1011, Abstract, 2:49–55, 7:47–49, 7:58–
`8:15; Ex. 1002 ¶ 83.
`Exclusive Licensee does not contest specifically Petitioner’s evidence
`or arguments with respect to this limitation. See Resp. 7–31.
`We find, on the basis of the evidence and explanation provided by
`Petitioner, that Wood’s description of the entry handler functionality in
`gatekeeper/entry handler component 110 discloses the recited limitation
`“receiving security data relating to computing conditions in which an
`authorization will be performed, wherein the security data comprises at least
`one indication of a type of communication link between the workstation and
`the security server, a geographic location of the workstation, or a time of
`access of the workstation” of claim 1.
`
`c. “determining a security policy from a plurality of
`predetermined security policies 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”
`With respect to this limitation, Petitioner relies on Wood’s description
`of predetermined “security policies” associated with “trust levels.” Pet. 36–
`39. Petitioner relies on Wood’s description, for example, that
`gatekeeper/entry handler component 110 interacts (3, 4)
`with authorization component 140 to determine whether
`the requested access is authorized. For some requested
`
`15
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`
`accesses and security policies (e.g., anonymous ftp access
`to certain archives), even a session without authenticated
`login credentials (trust level = 0) may be authorized. For
`others, a more substantial trust level may be required.
`Id. at 36 (quoting Ex. 1011, 9:19–26); see also Ex. 1011, 14:64–65 (“some
`security policies may allow anonymous access to certain resources”); 5:53–
`54 (“security requirements are expressed in terms of trust levels”); Ex. 1002
`¶ 84.
`
`Petitioner argues that Wood’s plurality of predetermined security
`policies includes, for example, a security policy that denies access to a
`sensitive resource (such as financial data) if the request is received over a
`dial-up line and originates from an unknown number, or is received outside
`of working hours. Pet. 37 (citing Ex. 1011, 9:59–67). Similarly, Petitioner
`points out, Wood discusses a different security policy that denies access to a
`salary tool if the request is made from outside the company’s network. Id.
`(citing Ex. 1011, 6:21–28). Petitioner compares this disclosure in Wood to
`the ’685 patent’s discussion of a security policy where a user requesting
`access to information automatically is denied between the hours of midnight
`and 6 a.m. Id. (citing Ex. 1001, 7:55–58; Ex. 1002 ¶ 85).
`Petitioner asserts that Wood indicates which rules should apply when
`specifying conditions for accessing a secure resource. Pet. 37. Petitioner
`relies, for example, on Wood’s description that
`a given security policy and associated trust level mappings
`may dictate a REFUSE response in response to an access
`request to a sensitive resource (such as financial data) by
`any client entity . . . if the access request is received over
`a dial-up line and originates from an unknown number or
`is received outside of working hours.
`Id. (quoting Ex. 1011, 9:59–67); see also Ex. 1002 ¶ 86.
`
`16
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`
`Petitioner argues that when Wood’s security architecture receives a
`request for access to a protected information resource, Wood selects a
`security policy to apply from among the plurality of predetermined security
`policies based on the required trust level, which is determined from the
`received “environment information.” Pet. 37–38 (quoting Ex. 1011, 14:48–
`51) (“A trust level requirement is determined for access to the requested
`resource in the context of the requesting session environment.”). Petitioner
`argues that Wood’s “environment information” can include an indication of
`a type of communication link between the user and the security architecture,
`a time of access, and a geographical location of the workstation. Id. at 38
`(citing Ex. 1002 ¶ 87).
`Petitioner further argues that “stored policy data” is used by Wood’s
`security architecture to “dynamically calculate[] a trust level based on . . .
`environment information.” Id. at 38–39. Petitioner argues that the type of
`environment information used by Wood is included among the parameters
`that affect previously stored policy data described in the Specification.
`Pet. 39; see Ex. 1001, 7:23–27 (“[E]xamples of parameters that affect the
`previously stored policy data are: the date, the time, the day of the week, the
`country, the data being accessed, the communication link . . . .”).
`Exclusive Licensee argues, “unlike the claimed invention of the
`’685 patent that determines a security policy based on stored policy data and
`one or more current computing conditions, Wood determines a security
`policy based on the information resource being accessed.” Resp. 7.
`Exclusive Licensee argues, “Wood’s security architecture always determines
`a security policy based on the information resource being accessed. It never
`determines a security policy based on ‘previously stored policy data’ and
`
`17
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`one condition in a set of computing conditions of the device accessing the
`information resource.” Resp. 18 (citing Ex. 2007 ¶¶ 62–64).
`Moreover, Exclusive Licensee argues, to the extent Petitioner is
`associating Wood’s “trust level requirement” with a security policy, because
`Wood assigns required trust levels based on the resource being requested,
`Wood does not determine a security policy based on previously-stored
`policy data and other computing conditions of the device requesting access,
`such as security data. Id. at 23–24 (citing Ex. 2007 ¶ 77).
`Exclusive Licensee further argues that Wood’s “current trust levels
`also do not meet the claimed determining a security policy based on stored
`policy data and received security data related to computing conditions.” Id.
`at 24 (citing Ex. 2007 ¶ 77). Exclusive Licensee argues that, although
`Wood’s current trust level may be determined based on environment
`information, “Wood’s current trust level is not a security policy because
`Wood’s current trust levels are not conditions or rules that must be met in
`order to grant access to a resource (i.e., a security policy).” Id. at 25 (citing
`Ex. 2007 ¶ 77).
`As an initial matter, claim 1 does not preclude consideration of an
`information resource in determining a security policy, as described in Wood.
`Although claim 1 requires “determining a security policy . . . based on . . .
`policy data and . . . the type of communication link . . . the geographic
`location of the workstation, or the time of access . . . ,” it does not preclude
`consideration of additional information in determining the policy.
`The “determining a security policy . . .” step of claim 1 is not written
`to be exclusionary, i.e., it does not expressly preclude consideration of other
`information or parameters in addition to “the received indication of the type
`
`18
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`of communication link between the workstation and the security server, the
`geographic location of the workstation, or the time of access of the
`workstation.” As long as Wood discloses what is required, the fact Wood
`may consider additional parameters, such as the information resource being
`accessed, does not mean that Wood fails to disclose the recited limitation.
`Moreover, the Specification states expressly that “security server 13
`consults the previously stored policy data in order to determine the security
`policy” and that “examples of parameters that affect the previously stored
`policy data are: . . . the data being accessed, . . . the type of secured data
`being requested from the data server 19, and so forth.” Ex. 1001, 7:23–30;
`see id. at 8:23–26. Thus, contrary to Exclusive Licensee’s argument, the
`Specification makes clear that the data accessed and the type of secured data
`requested from the data server (i.e., the “information resource”) may affect
`the previously stored policy data, which, in turn, may be used by the security
`server to determine the security policy.
`Exclusive Licensee’s argument that Wood “never determines a
`security policy based on ‘previously stored policy data’ and one condition in
`a set of computing conditions of the device accessing the information
`resource” does not withstand scrutiny. For example, the ’685 patent
`discusses a security policy where attempts to access a resource between
`midnight and 6 am are automatically denied. Ex. 1001, 7:55–58. In this
`example, the time of a request (i.e., a recited computing condition) is
`compared against a policy-specified period of midnight to 6 am. If the
`request falls within that period, a predetermined security policy applies and
`denies the request for access. If the request occurs outside that period, a
`
`19
`
`
`
`IPR2017-00338
`Patent 9,098,685 B2
`
`different policy may apply. Dr. Goldschlag confirmed this understanding of
`the ’685 patent. See Ex. 1040, 62:17–63:15.
`Wood discloses the same approach. Wood, like the ’685 patent,
`discloses comparing the time of an access request (i.e., a recited computing
`condition) against a specified time-period (e.g., “outside of working hours”).
`See Ex. 1011, 9:59–67. If the request falls within that period, Wood, like the
`’685 patent, applies a predetermined security policy that denies the request
`for access (REFUSE). Id. If the request occurs at other times, Wood, like
`the ’685 patent, applies another predetermined security policy to the request
`(ALLOW or REDIRECT). Id. at 9:40–55, 10:10–21; Ex. 1002 ¶¶ 59–60.
`Thus, each of the ’685 patent and Wood may 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. See Ex. 1002 ¶ 67; Ex. 1041 ¶ 12.
`In addition to security policies that are based upon the time of
`requested access, each of the ’685 patent (Ex. 1001, 9:16–37, 9:55–62) and
`Wood (Ex. 1011, 6:20–28) discloses security policies that are determined
`based on the location from which a request for access is made.
`Exclusive Licensee’s arguments with respect to Wood’s trust levels
`also are not persuasive. Exclusive Licensee argues that Wood’s “trust level
`requirement” does not satisfy the recited limitation because Wood assigns
`required trust levels based only on the r