throbber
Trials@uspto.gov
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket