Ex Parte 6,192,476 et al

Patent Trial and Appeal Board

Aug 23, 2013

90011521 (P.T.A.B. Aug. 23, 2013)

UNITED STATES PATENT AND TRADEMARK OFFICE
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
90/011,521 03/01/2011 6,192,476 13557.105128 8619
25226 7590 08/23/2013
MORRISON & FOERSTER LLP
755 PAGE MILL RD
PALO ALTO, CA 94304-1018
EXAMINER
BONSHOCK, DENNIS G
ART UNIT PAPER NUMBER
3992
MAIL DATE DELIVERY MODE
08/23/2013 PAPER
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________
BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte ORACLE AMERICA, INC.
Patent Owner & Appellant
____________________

Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1
Technology Center 3900

____________

Before HOWARD B. BLANKENSHIP, STEPHEN C. SIU, and DENISE M.
POTHIER, Administrative Patent Judges.

BLANKENSHIP, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

2
STATEMENT OF THE CASE
Patent Owner Oracle America, Inc. appeals under 35 U.S.C. § 134(b) from
the final decision of the Examiner to reject claims 1-7, 10-16, and 19-21 of US
6,192,476 B1 (“the '476 patent”). Claims 8, 9, 17, and 18 have been confirmed as
patentable. Oral hearing was on February 20, 2013. We have jurisdiction under 35
U.S.C. § 306.
We reverse.

Invention
The '476 patent describes determining whether a principal (e.g., a thread)
may access a particular resource. Abstract.
Figure 3 of the '476 patent is reproduced below.
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

3

Figure 3 is said to be a block diagram illustrating an exemplary access
controller, call stack, protection domain, and the object and methods being
executed by a thread sending a request to determine whether an action is
authorized to the access controller. '476 patent col. 3, l. 66 - col. 4, l. 4. Thread
306 is a thread executing on a computer system. Call stack 308 is a stack data
structure representing a calling hierarchy of the methods invoked by thread 306 at
any given instance. At the illustrated instance, call stack 308 contains a frame 310
for each invocation of a method (340-1 to 340-3) by a thread and not exited by that
thread. Each frame 310 corresponds to the method that has been called but not
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

4
exited by thread 306. When a method is exited, the frame 310 that corresponds to
the method is removed from the top of the call stack 308. When a method is
invoked, a frame corresponding to the method is added to the top of the call stack
308. Id. at col. 11, ll. 5-25.
For example, assume that thread 306 invokes method 340-1. While
executing method 340-1 thread 306 invokes method 340-2, while executing
method 340-2 thread 306 invokes method 340-3, and while executing method 340-
3 thread 306 invokes method 382. At this point, call stack 308 represents the
calling hierarchy of methods as shown in FIG. 3. When thread 306 exits method
382, frame 310-4 is removed from the stack. Id. at col. 11, ll. 26-35. Thread 306
might be executing method 340-3 and request a determination whether an action is
authorized by invoking the check permission method 382. Check permission
method 382 consults protection domains (250-1, 250-2, and 250-3) that are
associated with thread 306. As an example, the required permission to perform an
action of writing to a particular file (when executing method 340-3) might not be
authorized because the required permission is not encompassed by the only
permission included in protection domain object 250-1, associated with method
340-1, which has not exited. Id. at col 12, ll. 48-64.

Representative Claim
1. A method for providing security, the method comprising the
steps of:

detecting when a request for an action is made by a principal;
and

in response to detecting the request, determining whether said
action is authorized based on permissions associated with a plurality
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

5
of routines in a calling hierarchy associated with said principal,
wherein said permissions are associated with said plurality of routines
based on a first association between protection domains and
permissions.

Patent Owner’s Contentions
Patent Owner contends that the Examiner erred in rejecting:
I. Claims 1-7, 10-16, and 19-21 are under 35 U.S.C. § 102(b) as being
anticipated by Fischer (U.S. 5,412,717); and
II. Claims 1-7, 10-16, and 19-21 under 35 U.S.C. § 103(a) over Griffin (U.S.
5,958,050) and Chan
1
.

ANALYSIS
Claims 1-7, 10-16, and 19-21 -- § 102(b) Over Fischer
The Examiner rejects claim 1 of the '476 patent based on two alternative
findings with respect to what in Fischer corresponds to the claimed “principal.”
The Examiner finds that the claimed principal is “analogous to” the system
monitor described by Fischer. Ans. 54. The Examiner also finds that an
originating or “parent” program is a “principal.” Id. at 58-59; see also id. at 5-6.
Claim language in the instant proceeding must be read in light of the
specification as it would be interpreted by one of ordinary skill in the art. In re
Am. Acad. of Sci. Tech. Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004). The Office
must apply the broadest reasonable meaning to the claim language, taking into
account any definitions presented in the specification. Id. (citing In re Bass, 314

1
Patrick Chan et al., The Java™ Class Libraries: An Annotated Reference ,
Addison Wesley (© 1997).
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

6
F.3d 575, 577 (Fed. Cir. 2002)). As the Examiner acknowledges (Ans. 5), the
'476patent indicates what is meant by a “principal.” “A ‘principal’ is an entity in
the computer system to which permissions are granted. Examples of principals
include processes, objects and threads. A ‘permission’ is an authorization by the
computer system that allows a principal to perform a particular action or function.”
'476 patent col. 2, ll. 34-39. The Examiner does not offer or rely on any extrinsic
definition for the word “principal.” On this record, we interpret a “principal” to be
an entity, such as a process, an object, or a thread, in the computer system to which
permissions are granted.
First, we agree with Appellant that the rejection fails to show that the
“monitor program” as described by Fischer qualifies as a “principal” as defined by
the '476 patent. Fischer describes, as an anti-viral measure, using a program
control block (PCB) data structure that is used by the system monitor to control the
execution of an associated program. Fischer col. 10, ll. 8-13. The system monitor
limits the ability of a program about to be executed to the use of predefined
resources, such as data files and disk writing capabilities. Id. at col. 2, ll. 16-20.
Fischer further describes assigning program authorization information (PAI) to
define the types of resources and functions that a program is allowed to use. The
system monitor refers to the associated PAI for a program to confirm that an
operation is within the defined program limits; if not, program execution is halted.
Id. at col. 2, ll. 24-48. While the programs may contain entities (e.g., processes) to
which permissions are granted, the rejection does not identify any express or
inherent disclosure that the system monitor is an entity to which permissions are
granted, as required by claim 1 under proper interpretation of its terms.
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

7
We also agree with Appellant with respect to error in the Examiner’s second
reading of claim 1 on Fischer. According to the Examiner, “figure 5 and column
10, lines 24-36 of Fischer shows an execution stack (calling hierarchy) that
associates the parent originating program and associated PCB with associated
called programs. Here the ‘Originating Program’ (principle [sic]) has a plurality of
associated PCB sub-programs that it calls to execute (routines).” Ans. 59.
However, Fischer describes a PCB data structure 140 (Fig. 5) that
corresponds to an originating program (having PCB 180) that calls another
program (having PCB 170), which will, in turn, call the program 140. Each new
PCB will include a field (150) that points to the “previous” or calling PCB. A field
may also be included to identify the “next” PCB. Fischer col. 10, ll. 8-29.
When a called program finishes executing, the system removes
its associated PCB from the top of the executed stack, removes the
associated program from storage, removes the associated authorizing
information and accesses the program control block immediately
below it in the stack. When another program is called, the reverse
process occurs such that a new PCB is created which is placed on top
of the stack, which again points to the previous PCB as indicated in
field 150.

Id. at col. 10, ll. 30-39.
Thus, if the “originating program” is taken to be the “principal,” as
contemplated by the rejection, there is no determining, in response to detecting a
request for an action made by the originating program, whether the action is
authorized “based on permissions associated with a plurality of routines in a
calling hierarchy” associated with the principal, as claimed. That is, Fischer
describes an originating program that calls another program, which in turn may call
a next program. The “execution stack” or calling hierarchy is not consulted to
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

8
determine whether an action is authorized when the originating program makes a
request for the action, such as calling another program. Even if the execution stack
as described by Fischer might be considered to represent a “plurality of routines in
a calling hierarchy,” Fischer does not describe determining whether a request for
an action by the originating program is authorized based on (plural) permissions
associated with a “plurality of routines” in the execution stack.
In support of what appears to be yet another alternative reading of claim 1
on the prior art, the Examiner points out (Ans. 9-10, 28-29) that Fischer
incorporates by reference two patents that further describe a preferred “certificate
hierarchy.”
In the presently preferred embodiment, signatures are verified through
a certificate hierarchy. The preferred methodology for determining
whether the signatures are valid and whether they are trusted by the
caller and whether the authority delegated by the program is permitted
to have been delegated by the signer is taught in the inventor’s U.S.
Pat. Nos. 4,868,877 and 5,005,200.

Fischer col. 16, ll. 53-60.
Notably, U.S. 4,868,877 discloses that “[a]ll certificates must be
accompanied by signatures which are themselves authorized by antecedent
certificates.” Col. 17, ll. 26-28. U.S. 5,005,200 discloses that “B’s signature and
the hierarchy of all certificates and signatures which validate it are kept by A and
sent along whenever A uses his certificate.” Col. 20, ll. 10-12. In view of the
teachings of the patents that Fischer incorporates by reference, the Examiner finds:
The digital certificates and signatures take into account permissions of
programs other that [sic] the requesting program when determining
whether a requested act may be performed. Thus Fischer’s teachings
are not limited to the one and only program (the requesting program)
located at the top of the call stack (execution stack), but actually
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

9
require consideration of permissions associated with a plurality of
routines in the calling hierarchy of the digital signature / certificate
authorizations.

Ans. 10. The Examiner further notes “that for the purpose of [this] reexamination
the term “routine” includes within its scope such terms as function, operation,
program, method, or the concept of ‘access’ to a resource.” Id.
While the references might teach that signatures are verified through a
certificate “hierarchy,” a “certificate” is not a routine. A “certificate” is a data
structure. Goldberg Declaration ¶ 18; Fischer col. 6, ll. 25-48. But instant claim 1
recites “a plurality of routines in a calling hierarchy” (emphasis added). One of
ordinary skill in the art would not interpret a “routine” to be synonymous with a
data structure. A “routine” may be defined as “[a]ny section of code that can be
invoked (executed) within a program. A routine usually has a name (identifier)
associated with it and is executed by referencing that name. Related terms (which
may or may not be exact synonyms, depending on the context) are function,
procedure, and subroutine.” Microsoft® Computer Dict., Fifth Ed. 2002. There is
a “heavy presumption” that a claim term carries its ordinary and customary
meaning. CCS Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1366 (Fed. Cir.
2002). The ordinary and customary meaning of “routine” does not include within
its scope “the concept of ‘access’ to a resource,” as alleged at page 10 of the
Answer. The rejection fails to rebut the presumption that the word “routine” as
used in claim 1 of the '476 patent carries its ordinary and customary meaning.
Moreover, while the references might describe certificates in a hierarchy, the
rejection does not identify in the references any express description of a “plurality
of routines” that may reside in a “calling hierarchy,” or in any hierarchy. A
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

10
“hierarchy,” to one of ordinary skill in the art, is normally thought of as an
organization for entities such as records and files, rather than routines.
hierarchy n. A type of organization that, like a tree, branches
into more specific units, each of which is “owned” by the higher-level
unit immediately above. Hierarchies are characteristic of several
aspects of computing because they provide organizational frameworks
that can reflect logical links, or relationships, between separate
records, files, or pieces of equipment. For example, hierarchies are
used in organizing related files on a disk, related records in a database,
and related (interconnected) devices on a network. In applications
such as spreadsheets, hierarchies of a sort are used to establish the
order of precedence in which arithmetic operations are to be
performed by the computer. See also hierarchical file system.

Microsoft® Computer Dict., Fifth Ed. 2002.
Further, the rejection fails to show that routines that might be utilized to
examine certificates arranged in a hierarchy are themselves necessarily structured
in the form of a hierarchy. See In re Robertson, 169 F.3d 743, 745 (Fed. Cir. 1999)
(“To establish inherency, the extrinsic evidence ‘must make clear that the missing
descriptive matter is necessarily present in the thing described in the reference, and
that it would be so recognized by persons of ordinary skill.’”) (citation omitted).
“[A]bsence from the reference of any claimed element negates anticipation.”
Kloster Speedsteel AB v. Crucible, Inc., 793 F.2d 1565, 1571 (Fed. Cir. 1986)
(citation omitted), overruled on other grounds by Knorr-Bremse Systeme Fuer
Nutzfahrzeuge GmbH v. Dana Corp., 383 F.3d 1337 (Fed. Cir. 2004). We cannot
sustain the § 102(b) rejection of claim 1. Because each of independent claims 5, 6,
10, 14, 15, and 19 contains limitations substantially similar to those of claim 1 for
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

11
which the rejection for anticipation fails, we do not sustain the rejection of claims
1-7, 10-16, and 19-21 under 35 U.S.C. § 102(b) as being anticipated by Fischer.
2

Claims 1-7, 10-16, and 19-21 -- § 103(a) Over Griffin and Chan
The Examiner rejects claim 1 under § 103(a) over the combination of Griffin
and Chan. Appellant acknowledges that the rejection is based on alternative
readings of a “principal” in Griffin. The claimed “principal” is deemed to
correspond to the “trust manager” or to an “executing program” in the reference.
E.g., App. Br. 29-30.
In one “scenario,” as denoted by Appellant, the Examiner finds that Griffin
teaches a “principal” -- an executing program -- that may, for example, retrieve
data from a Web site. Griffin col. 5, ll. 21-24; Ans. 31-32. The trust manager
examines each new class before it is allowed to load, execute, or otherwise gain
control of the resources by examining a set of claims in a policy file and a
certificate repository. Id. at col. 3, ll. 34-38. The class loader 124 (Fig. 3) does not
pass the class on to runtime executive 126 unless it receives an “OK-to-load”
signal from trust manager 122. Id. at col. 7, ll. 14-19.
Appellant contends that Griffin fails to disclose or suggest “determining
whether said action is authorized based on permissions associated with a plurality
of routines in a calling hierarchy,” as claimed. Appellant acknowledges that
Griffin teaches examining each new class before it is allowed to execute, but
submits that Griffin does not teach “examining permissions associated with classes
or subclasses after they have been loaded and after their routines (methods) are

2
Because we do not sustain any rejection that relies on Fischer as evidence of
unpatentability, we do not reach Appellant’s arguments that the reference fails to
present a substantial new question of patentability.
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

12
already executing and ‘in a calling hierarchy’ as required by the claims.” App. Br.
31.
However, as made plain by the Appeal Brief (e.g., at 31-32), the Reply Brief
(e.g., at 21-22), and the Oral Hearing (e.g., Oral Hearing Tr. at 11 and 13),
Appellant is improperly reading disclosed limitations into the claims. “[T]he '476
Patent makes clear that the recited ‘routines in a calling hierarchy’ requires
routines that have already been invoked (i.e., activated or called) by or on behalf of
the executing principal (e.g., thread, process) but have not been exited, thus
requiring that the permissions indeed be associated with routines invoked and in an
execution stack.” App. Br. 31 (offering a technical dictionary definition for the
word “invoked.”). “I think it’s very clear from our patent specification that we
define a calling hierarchy as routines that have been invoked but not yet exited,
which means they’re on a call stack. And again, Griffin checks everything --
checks classes, let alone routines, but checks classes prior to loading them. So
there's nothing on a call stack, there’s nothing in execution.” Oral Hearing Tr. at
11, ll. 12-16.
Claim 1 recites determining whether the action is authorized based on
permissions associated with a plurality of routines in a calling hierarchy. The
Specification does not “define” a calling hierarchy as routines that have been
invoked (i.e., on a call stack). Rather, the Specification provides that, “according
to one aspect of the invention,” “[a] calling hierarchy indicates the routines (e.g.
functions, methods) that have been invoked by or on behalf of a principal (e.g.
thread, process) but have not been exited.” Spec. 3:7-10. The Specification does
not provide a limiting definition for the term “calling hierarchy.” Claim 1recites
determining whether the action is authorized based on permissions associated with
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

13
a plurality of routines in a calling hierarchy associated with the principal. If claim
1 were to be limited to calling hierarchies that indicate the routines that have been
invoked by or on behalf of the principal but have not been exited, the claim could
have been drafted with a commensurate limitation. Cf. Spec. 3:33-34 (“According
to another aspect of the invention, certain routines may be ‘privileged’”); claims 6
and 15 (requiring that a first routine in the calling hierarchy is “privileged”).
Further, the Declarations submitted by Professor Goldberg presume that the
claims require routines that have been invoked but not exited (e.g., Supplemental
Decl. ¶¶ 5, 10). The expert’s implicit opinion on claim interpretation is entitled to
little weight. Neither the Declarations nor the briefs provide any basis for the
presumption that one of ordinary skill in the art would interpret the claims as if
they were limited to unclaimed details of a disclosed embodiment.
However, we are in ultimate agreement with Appellant that the proffered
§ 103(a) rejection over Griffin and Chen fails to demonstrate the obviousness of
the subject matter of claim 1. Griffin does teach certificates in the form of data
structures that “can be specified in hierarchical form.” Griffin col. 3, ll. 60-63; see
also col. 3, ll. 33-57, col. 4, ll. 40-59. Whether the claimed principal is taken to
correspond to the “trust manager” or an “executing program” in Griffin, the
rejection fails to show disclosure or suggestion of a plurality of routines in a
calling hierarchy as claimed.
In one “scenario,” the Examiner submits that a “nested hierarchy of
certificates” in Griffin that are “required to be read and proven are reads on [sic]
the ‘plurality of routines.’” Ans. 34. While the certificates are not “routines,” the
rejection might refer to routines that perform the “reading” and “proving” of the
certificates. “[Griffin’s] program further has associated with it a plurality of
Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

14
routines in a hierarchy, each level having an associated class that need be
examined to determine potential resource use of the portion of code for the
particular sub-program being executed (see column 3, lines 33-57 and in figure
5).” Ans. 74. However, we do not find any clear disclosure or suggestion of a
“plurality of routines in a hierarchy” in Griffin. Nor does the rejection set forth a
convincing rationale in support of why one of ordinary skill in the art would have
considered it obvious to provide a plurality of routines in a hierarchy for
determining whether an action is authorized in response to detecting a request for
the action by a principal.
The Examiner submits that “the addition of Chan merely defines a use of
Class Libraries usable via the Java applets and associated ‘class loader’ used with
in [sic] the Griffin reference (see column 6, lines 33-51) and defines details
regarding how a security manager evaluates class / subclass permissions about the
‘current execution context’ (see pages 1188 and 1189).” Ans. 76-77. Chan as
applied in the rejection thus does not remedy the deficiencies in Griffin. Because
each of independent claims 5, 6, 10, 14, 15, and 19 contains limitations
substantially similar to those of claim 1 for which the rejection for obviousness
fails, we do not sustain the rejection of claims 1-7, 10-16, and 19-21 under 35
U.S.C. § 103(a) over Griffin and Chan.

DECISION
The Examiner’s decision to reject claims 1-7, 10-16, and 19-21 is reversed.

REVERSED

Appeal 2013-001459
Control No. 90/011,521
Patent US 6,192,476 B1

15

ack

Patent Owner:

MORRISON & FOERSTER LLP
755 PAGE MILL RD
PALO ALTO, CA 94304-1018

Third Party Requester:

KING & SPALDING
1180 PEACHTREE STREET, N.E.
ATLANTA, GA 30309-3521