Ex Parte Lin et al

Patent Trial and Appeal Board

Feb 18, 2014

11619672 (P.T.A.B. Feb. 18, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________________

Ex parte DAH-HAUR LIN, SATOSHI HADA,
ANTHONY JOSEPH NADALIN, and
NATARAJ NAGARATNAM
____________________

Appeal 2012-001999
Application 11/619,672
Technology Center 2400
____________________

Before: ROBERT E. NAPPI, MICHAEL W. KIM, and
SCOTT A. DANIELS, Administrative Patent Judges.

DANIELS, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2012-001999
Application 11/619,672

2
STATEMENT OF CASE
Appellants appeal under 35 U.S.C. § 134 from a rejection of claims 1-
22. Claims 1, 10, 16 and 20 are independent. We have jurisdiction under 35
U.S.C. § 6(b).
We AFFIRM.
THE INVENTION
The claims relate to a method and apparatus permitting authorized
users access to particular shared resources in a computer system. The user,
or principal, is provided with a role-based authorization having an associated
condition, or conditions, which together define a conditional permission
class. Spec. 4, ll. 7-20. Claim 1, reproduced below, is illustrative of the
claimed subject matter:
1. A method of access control, comprising:
configuring a security policy having a permission to
include a condition;
responsive to a request to access a resource, evaluating
the configured policy; and
authorizing access to the resource if the condition is
satisfied.

REFERENCE
The prior art relied upon by the Examiner in rejecting the claims on
appeal is:
Kinser US 2006/0277595 A1 Dec. 7, 2006

REJECTION
The Examiner made the following rejection:
Claims 1-22 stand rejected under 35 U.S.C §102(e) as anticipated by
Kinser. Ans. 4.
Appeal 2012-001999
Application 11/619,672

3
ANALYSIS
Claims 1-9, 11-15, 21 and 22 as anticipated by Kinser1
The Examiner found that Kinser’s security service discloses a method
of providing access control to a user including the claimed steps of (a)
configuring a security policy having a permission to include a condition
responsive to a request to access a resource; (b) evaluating the configured
policy; and (c) authorizing access to the resource if the condition is satisfied,
as called for in claim 1. Ans. 4-5, Clms. Appx. The Examiner found that at
least paragraph [0005] of Kinser describes a security policy including a user
request for permission such as recited in step (a), comparison of the
requested permission to permissions allocated to the role assigned to the user
as in step (b), and allowing access to the resource as in step (c) if the
evaluation determines the role is allocated the requested permission. Ans. 4-
5. Importantly, the Examiner determined that Kinser discloses an additional
condition could be associated with the permission in step (a), stating “[a]
further example condition may require that a license obligation be met. For
example, the license obligation may require that no more than a
predetermined number of principals may access a resource simultaneously.”
Ans. 5 citing Kinser, para. [0081].
Appellants argue that “a principal,” a “security role,” and a
“permission” are distinct elements of claim 1, and that a “condition” is one
of a variety of conditions “that is associated to the permission.” App. Br. 8-
9. Appellants assert specifically that in Kinser, “constraints” i.e.

1 The Examiner applied the single ground anticipation rejection to
independent claims, 1, 10, 16, and 20 as a group. For purposes of clarity in
our decision, we address each of the independent claims, and any respective
dependent claims, separately.
Appeal 2012-001999
Application 11/619,672

4
“conditions,” are associated with a role, and evaluated to determine the
status of a role, but “[i]n contrast, in the subject claim 1, the ‘condition’ is
applied to the ‘permission’ itself.” App. Br. 9.
We understand, as Appellants argue, that the claimed “condition” is
associated, as an additional constraint, with the “permission” recited in claim
1. However, this does not explain why Kinser’s additional condition
described at paragraph [0081], such as a license obligation which conditions
a permission on current use or allocation of a particular resource by other
users, does not create a “conditional permission.” We are not persuaded by
Appellants’ argument because Kinser’s license obligation condition is not
associated with a “role” or “security role,” but is distinctly applied as an
additional condition or constraint to determine permission to access a
resource in accordance with a predetermined number of users, in addition to
their security role(s). See Kinser paras. [0081-82].
Appellants’ argument that Kinser associates permissions or
constraints based on a static or dynamic role is also not persuasive.2 App.
Br. 8-9. The fact that a user’s permissions, or privileges, may change at
times does not alter our understanding that other conditions aside from role
based permissions are applied by Kinser to the underlying permission.
Kinser, paras. [0037-38].
Based on this understanding, we are also not persuaded that Kinser
fails to evaluate a “conditional permission to provide an access control

2 A “dynamic role” as described in Kinser is essentially a role that changes,
for example between “active” and “inactive.” If a role were “active” for
example for a particular user, the user would have the associated permission,
if “inactive, the principal does not possess the privileges associated with the
role.” Kinser, para. [0037]
Appeal 2012-001999
Application 11/619,672

5
decision.” App. Br. 10. Kinser’s security policy evaluates not only the
underlying role based permission but also the additional conditions or
constraints, such as the license obligation example from paragraph [0081]
discussed supra. Kinser, para. [0082].
Appellants further contend that the “role” as described in the
Specification is a separate and distinct element from the claimed
“permission” and that the Examiner’s interpretation subsumes these distinct
elements. App. Br. 11. We do not agree that the Examiner has interpreted
“permission” sufficiently broad so as to subsume “role”. App. Br. 11. First,
this argument is not commensurate in scope with the claim. There is no
recitation in claim 1 of “role.” Second, the Examiner explained from
Kinser’s disclosure that on one hand, paragraph [0005] discloses the role-
based permissions, and on the other hand, “[i]n the example provided in
paragraph 0081, Kinser teaches a scenario where the conditional permission
is not based on the ‘role’ of the user[;] rather, it is based on whether the
condition of a license obligation is being met.” Ans. 9.
Appellants also argue that “Kinser bases its access control decision on
a role that has been evaluated against a constraint. This teaching - in and of
itself - is not sufficient to meet the high burden to establish anticipation.”
App. Br. 12. This argument is also not persuasive because claim 1 does not
exclude a role-based constraint in a security policy.3 Giving the claim term

3 Appellants’ Specification clearly explains that the security policy “is role
based. In particular, and with reference to FIG. 1, the model is based on the
concept of a security role 100, which is a logical grouping of users (e.g.,
managers, tellers, customers) typically defined by an application component
developer or assembler. A deployer typically maps a given security role to
one or more security identities 102 (e.g., a principal, a group, and the like) in
the operational environment.” Spec. 1-2.
Appeal 2012-001999
Application 11/619,672

6
“security policy” the broadest reasonable interpretation, the Examiner has
provided a sound basis explaining why Kinser meets the recited elements of
a conditional permission as set forth in Appellants’ claim 1. Moreover, what
matters is whether all of the limitations of the claim are found in the
reference, not whether the reference “teaches” what the subject application
teaches. Kalman v. Kimberly-Clark Corp., 713 F.2d 760, 772 (Fed. Cir.
1983).
Accordingly, we sustain the anticipation rejection of claim 1. Claims
2-9, 11-15, 21, and 22 depend from claim 1 and are not argued separately.
See App. Br. 8-13. These claims fall with claim 1.
Anticipation of claims 10, 16 and 20 – The PTO burden
Appellants argue that the Examiner does not address the specific
limitations in independent claims 10, 16 and 20, and thus has not met the
burden of supporting a prima facie case of anticipation. App. Br. 15-16,
Reply Br. 1-2. Appellants argue specifically with respect to claim 16, for
example, that “[n]either the actual rejection (page 3) [n]or the Examiner's
‘Response to Arguments’ (pages 2-3) address this clear deficiency in the
Office’s proofs regarding alleged anticipation of independent claim 16.”
App. Br. 16. Appellants assert that by not addressing the claim limitations
of each independent claim individually, “this is a failure of proof, as each
limitation in each claim is material to patentability.” Reply Br. 1-2.
In order for a prior art reference to serve as an anticipatory reference;
it must disclose every limitation of the claimed invention, either explicitly or
inherently. See In re Schreiber, 128 F.3d 1473, 1477 (Fed. Cir. 1997). To
anticipate, every element and limitation of the claimed invention must be
Appeal 2012-001999
Application 11/619,672

7
found in a single prior art reference, arranged as in the claim. Karsten Mfg.
Corp. v. Cleveland Golf Co., 242 F.3d 1376, 1383 (Fed. Cir. 2001).
The Examiner addressed all the limitations of claims 1, 10, 16 and 20
as a group. Ans. 8-9. Pointing to paragraphs [0005] and [0081] in Kinser,
the Examiner found that “Kinser teaches a scenario where the conditional
permission is not based on the ‘role’ of the user, rather, it is based on
whether the condition of a license obligation is being met. Therefore Kinser
does read on the claimed language.” Ans. 9.
We conclude that the Examiner has established a prima facie case of
anticipation. Furthermore, and contrary to Appellants’ arguments, as set
forth supra with respect to claim 1, the Examiner has established that the
Kinser reference discloses a conditional permission, i.e. a role-based
permission which further includes an additional, non-role based condition
which must be satisfied in an evaluation or determination step by the
security system to allow access to a computer based resource. Ans. 9 citing
Kinser paras. [0005] and [0081]. The Examiner has further established that
Kinser discloses that such a conditional permission may be implemented by
a context manager in a Java programming environment including, by way of
example, a JACC API to access a resource, thus largely satisfying the
limitations in claims 10, 16, and 20 that are additional to those set forth in
independent claim 1. Ans. 5 citing Kinser paras. [0025] and [0048], see also
Final Rej. 3-4.
In view of the nature of Kinser’s disclosure, we determine that it is
reasonable to conclude that a conditional permission implemented in a Java
environment would necessarily encompass specific Java based programming
architectures such as “wrapping” a permission in a condition as in claim 10,
Appeal 2012-001999
Application 11/619,672

8
and defining a “conditional permission class” and one or more “condition
classes” as recited in independent claim 16, as well as the “policy
configuration class” and “policy enforcement class” in claim 20. (Emphasis
added.) We are not persuaded that particular and descriptive verbs and
nouns such as “wrapping,” “a set,” “class” or “classes,” or “JACC-
compliant” distinguish the claimed conditional permission from Kinser.
Such terms are necessarily or inherently a sequence of programming
instructions, routines, callable units or program architecture which are the
very syntax of many programming languages, including Java. There is
nothing in these descriptive words, no unique element, or step, that is not
disclosed or understood by those of ordinary skill in the art from the Java
programming environment discussed in Kinser.
That such specific terms or phrases as recited in independent claims
10, 16, and 20 are not found in Kinser is of no consequence. We are not
apprised of error in the Examiner’s findings merely by divergences in the
terminology. “These elements must be arranged as in the claim under
review but this is not an ‘ipsissimis verbis’ test.” In re Bond, 910 F.2d 831,
831 (Fed. Cir. 1990). The Examiner has established a prima facie case of
anticipation. Under these circumstances Appellants have the burden of
proving that the prior art does not necessarily or inherently possess the
claimed characteristics. In re Ludtke, 441 F.2d 660, 664 (CCPA 1971).
Appeal 2012-001999
Application 11/619,672

9
Claim 10 as anticipated by Kinser
Appellants argue that the “conditional permission” recited in claim 10
is not disclosed by Kinser for the same reasons as with respect to claim 1.
App. Br. 13-14. For the reasons set forth above, we are not persuaded by
this argument.
Appellants also assert that Kinser does not disclose “the step of
‘wrapping a role-based permission in a conditional permission class’ where
the ‘conditional permission class [has] a condition associated with the role-
based permission.’”
Reviewing Appellants’ Specification, we find the term “wrapping,” to
be most clearly explained by the following portion of the specification:
In particular, the invention provides for a conditional
permission, which is preferably implemented as a Java
ConditionalPermission class. During policy configuration,
certain ‘Conditions’ may be associated with a standard Java
Permission object using the ConditionalPermission
class…[d]uring runtime, an “implies” method in the
ConditionalPermission class returns true if the argument
permission is implied by the wrapped permission and the
additional “Conditions” are evaluated to be true.

Spec. 4, ll. 7-15. A “wrapper” as known in the computer arts is a
programming construct generally defined as:
Code which is combined with another piece of code to
determine how that code is executed. The wrapper acts as an
interface between its caller and the wrapped code. This may be
done for compatibility, e.g. if the wrapped code is in a different
programming language or uses different calling conventions, or
for security, e.g. to prevent the calling program from executing
certain functions. The implication is that the wrapped code can
only be accessed via the wrapper.
Appeal 2012-001999
Application 11/619,672

10
Computer Dictionary Online, http://www.computer-dictionary-
online.org/index.asp?q=wrapper, (last visited January 28, 2014) (emphasis
added).

Giving the claims the broadest reasonable interpretation, we
determine that the phrase “wrapping a role-based permission in a conditional
permission class” in claim 10 does not patentably distinguish the claimed
method of access control from the security system disclosed by Kinser.
Kinser associates the additional condition of allocating the resource based on
criteria, such as a license obligation, along with the role-based constraint.
Moreover, given that Kinser describes that Java classes can “encapsulate”
objects into a single object, as Appellants acknowledge, Appellants provide
no explanation or technical reason as why the step of “wrapping” patentably
distinguishes the claimed method in this regard. App. Br. 14, Reply Br. 5-6.
We are not apprised of Examiner error in the anticipation rejection,
and we sustain the rejection of claim 10.
Claims 16-19
Appellants argue that Kinser does not disclose the “conditional
permission class and at least one of the condition classes are configurable to
specify a condition associated with a role-based permission,” as called for in
claim 16. App. Br. 16.
As discussed supra the Examiner addressed all the limitations of
claims 1, 10, 16 and 20 as a group. Ans. 8-9. Pointing to paragraphs [0005]
and [0081] in Kinser, the Examiner found that “Kinser teaches a scenario
where the conditional permission is not based on the ‘role’ of the user[;]
rather, it is based on whether the condition of a license obligation is being
met. Therefore, Kinser does read on the claimed language.” Ans. 9.
Appeal 2012-001999
Application 11/619,672

11
Appellants have provided no evidence or explanation to rebut the
Examiner's prima facie case of anticipation. Appellants merely argue that
Kinser “does not teach a ‘conditional permission class’ or any of the other
recited elements in claim 16.” App. Br. 16. None of Appellants’ arguments
asserting the lack of the individual elements of claim 16 explain why such
elements are not disclosed by Kinser, nor why the implementation of a
conditional permission in a Java programming environment does not result
in a conditional permission class and the condition classes being
“configurable to specify a condition associated with a role-based
permission;” as recited in claim 16.
Accordingly, we sustain the anticipation rejection of claim 16. Claims
17, 18, and 19 depend from claim 16 and are not argued separately. See
App. Br. 15-16. These claims fall with claim 16.
Claim 20
Appellants argue that claim 20 requires system components including:
a policy configuration class executable by a first
processor to create a security policy that includes a permission
configured to include a condition; and
a policy enforcement class executable by a second
processor to evaluate the security policy and return an
authorization if the condition is satisfied.

Appellants assert only that these limitations are absent from Kinser.
App. Br. 16-17, Reply Br. 7. This argument provides no evidence or
technical explanation as to why a processor, a policy configuration class, and
a policy enforcement class, are not necessarily or inherently disclosed by
Kinser’s reference to an application server containing a Java based context
manager. See App. Br. 16-17, Reply Br. 7. With respect to Appellants
Appeal 2012-001999
Application 11/619,672

12
argument that Kinser does not disclose “a security policy that includes a
permission configured to include a condition,” we are again not persuaded
by this argument, and refer to our analysis supra in regards to claim 1. App.
Br. 17.
Accordingly, we sustain the anticipation rejection of claim 20.

DECISION
For the above reasons, the Examiner’s rejection of claims 1-22 is
AFFIRMED.

No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv) (2011).

AFFIRMED

Klh