Ex Parte Erlingsson

Patent Trial and Appeal Board

Aug 29, 2014

10456805 (P.T.A.B. Aug. 29, 2014)

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.
10/456,805 06/06/2003 Ulfar Erlingsson 2525.0770001 7444
66777 7590 08/29/2014
STERNE, KESSLER, GOLDSTEIN & FOX P.L.L.C.
1100 NEW YORK AVENUE, N.W.
WASHINGTON, DC 20005
EXAMINER
ALMEIDA, DEVIN E
ART UNIT PAPER NUMBER
2432
MAIL DATE DELIVERY MODE
08/29/2014 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 ULFAR ERLINGSSON
____________________

Appeal 2012–002724
Application 10/456,805
Technology Center 2400
____________________

Before JOSEPH L. DIXON, JAMES R. HUGHES, and ERIC S. FRAHM,
Administrative Patent Judges.

DIXON, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2012–002724
Application 10/456,805
2
STATEMENT OF CASE
Appellant appeals under 35 U.S.C. § 134(a) from a rejection of claims
1, 3–6, 8–11, and 13–15. We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.

The claims are directed to implementing a secure application
execution environment using derived user accounts for Internet content.
Claim 1, reproduced below, is illustrative of the claimed subject matter:
1. A method for providing secure content use comprising:

receiving content from a resource at a computing system;

determining if the received content is trusted or untrusted
content;

accessing the received content in a regular derived user
account (DUA) when the content is trusted; and

accessing the received content in a protected DUA when
the content is untrusted;

wherein the protected DUA provides unrestricted access
to the received content, and wherein said protected DUA and
said regular DUA are both associated with a same user and are
dynamically invoked based on the received content within a
same integrated user environment of said same user, thereby
enabling an integrated execution environment for both trusted
and untrusted content.

REFERENCES
The prior art relied upon by the Examiner in rejecting the claims on
appeal is:
Chan US 2002/0019941 A1 Feb. 14, 2002

Appeal 2012–002724
Application 10/456,805
3
Cowart, “Special Edition Using Microsoft® Windows® XP Professional”
(Dec. 4, 2001)

REJECTION
The Examiner made the following rejection:
Claims 1, 3–6, 8–11, and 13–15 stand rejected under 35 U.S.C
§ 103(a) as being unpatentable over Chan and Cowart.

ANALYSIS
Appellant contends Chan does not disclose “accessing the received
content in a protected DUA when the content is untrusted” and “wherein the
protected DUA provides unrestricted access to the received content,” as
recited in claim 1 (Br. 13–15). Appellant also contends Cowart does not
disclose the claim 1 limitation “wherein said protected DUA and said regular
DUA are both associated with a same user” (Br. 15–17). Further, Appellant
contends that Cowart does not disclose “wherein said protected DUA and
said regular DUA . . . are dynamically invoked based on the received content
within a same user environment of said same user, thereby enabling an
integrated execution environment for both trusted and untrusted content,” as
also recited in claim 1 (Br. 18–22).
We begin by construing the claim 1 term “derived user account
(DUA).” We look to Appellant’s Specification to define this term of art:
DUAs may have all the properties of traditional user accounts
including, but not limited to, its own state, distinct privilege and
access control rules, its own unique identifier (such as a
security token), and ownership of any system resources. In
addition, DUAs are linked to at least one particular existing
user account (the Original User Account, or OUA). Through
Appeal 2012–002724
Application 10/456,805
4
use of a DUA, its OUA may be selectively isolated from system
operations taking place in the DUA’s context.

(Spec. ¶ 38). In operation, a DUA may be implemented as follows:
FIG. 2 illustrates the steps of a method for accessing a
resource using a derived user account consistent with the
present invention. In one embodiment, a software application,
P, requests access to a resource, X (step 210). A “resource”
may be, for example, state information, such as data that lies in
memory, file systems, registry configurations, other
applications, processes, network ports, semaphores, window
handles in graphical user interface (“GUI”) systems, hardware
devices such as a soundcard or printer, or other named
abstractions. The system determines if the software application
is already running in the context of a DUA (step 220). . . .

If the software application is not running in the context of
the DUA, the application determines if a DUA should be
“created” (step 222).

(Spec. ¶¶ 39–40).
[A] DUA shell may be created by creating a new, possibly
restricted, login session or token for the OUA (called OUA’, or
“OUA prime”). OUA’ is distinct and separate from the original
OUA session or token, but may have all the same privileges for
resources as the OUA, such as, for example, ability to use the
same display. In some exemplary embodiments, OUA’ may
have fewer capabilities than OUA (for example, may not be
able to shut down the machine or modify the screen resolution).

(Spec. ¶ 43)

Referring back to FIG. 2, once a DUA is created, the
application is executed using the DUA, not the original user
account. . . . If . . . the DUA is a token, as is also described
above, the application may execute based on permissions in the
DUA token.

Appeal 2012–002724
Application 10/456,805
5
(Spec. ¶ 66) (emphasis added). Thus, based on Appellant’s Specification, a
DUA is derived from an existing user account and is used to access system
resources. A DUA can be a token, and can have the same access to system
resources as the original user account or more restricted access to system
resources, as provided by the permissions in the token.
Based on this construction, we find Chan discloses the argued features
of claim 1. First, we agree with the Examiner and find Chan discloses
“accessing the received content in a protected DUA when the content is
untrusted” and “wherein the protected DUA provides unrestricted access to
the received content.” As described in Chan, “[w]hen a user logs on to the
Windows NT operating system and is authenticated, a security context is set
up for that user, which includes building an access token 60. . . . The token
60 also includes a privileges field 68 listing any privileges assigned to the
user.” (Chan, ¶ 35). Further,
A restricted token is created from an existing access token
(either restricted or unrestricted) as described below. . . . The
primary use of a restricted token is for a process to create a new
process with a restricted version of its own token. The
restricted process is then limited in the actions it may perform
on resources.
(Chan, ¶¶ 42–43).
By way of example, . . . an application such as Internet
Explorer can use restricted tokens to execute untrusted
executable code under different processes, and control what
those process can do within the user’s overall access rights and
privileges. To this end, the Internet Explorer application
creates a restricted token from its own token, and determines
which restricted security IDs will be placed in the restricted
token. Then, the untrusted executable code is restricted to
accessing only those objects that the restricted context may
access.

Appeal 2012–002724
Application 10/456,805
6
(Chan, ¶ 53). Here, Chan’s use of a restricted token to access untrusted
executable code through an Internet Explorer process meets the limitation of
“accessing the received content in a protected DUA when the content is
untrusted,” as recited in claim 1. The restricted token is a “protected DUA”
because it limits the amount of access to system resources by the untrusted
executable code.
We disagree with Appellant’s argument that “the Office Action fails
to point to a single portion of Chan in which it is suggested that untrusted
content is allowed to run in the administrative account without restriction”
(Br. 14). This argument depends on an incorrect reading of the claim 1
limitation “wherein the protected DUA provides unrestricted access to the
received content.” Based on the plain meaning of this limitation, consistent
with the Specification, it is the access to the content that is “unrestricted,”
not the content’s access to system resources that is “unrestricted,” as
Appellant’s argument suggests (see Br. 14). For example, the Specification
describes “mechanisms that prevent a user of an application from accessing
untrusted content such as Internet content in a normal manner, which can
pose high-security risk. By intercepting the request, content (i.e., untrusted
content) can be accessed in a secure environment of a protected DUA.”
(Spec. ¶ 108). Accordingly, the protected DUA allows an application to
access the untrusted content. But, the protected DUA does not provide the
content with unrestricted access to system resources once it is downloaded.
To the contrary,
the purpose of the protected DUA 704 is to contain the scope of
any operations that result from activating the tagged file or
email attachment. As such, a separate protected DUA 704 can
be created when tagged files or email attachments are activated.
In one example, the protected DUA 704 for containment
Appeal 2012–002724
Application 10/456,805
7
operates based on at least privilege, and grants limited access
rights to the application launched to activate the tagged file or
email attachment.

(Spec. ¶ 144) (emphasis added). Thus, claim 1 requires allowing
unrestricted access to untrusted content through the use of a protected DUA,
but does not require providing the untrusted content with unrestricted access
to system resources, which would be inconsistent with Appellant’s
Specification. Similarly, Chan’s restricted token allows an application, such
as Internet Explorer, to download untrusted executable code without
specifying any limit on that download access, but the restricted token
provides the code with only limited access to system resources once it is
downloaded and executed (see Chan, ¶ 53). Thus, Chan also discloses the
limitation “wherein the protected DUA provides unrestricted access to the
received content,” as recited in claim 1.
Second, we agree with the Examiner (Ans. 7–8) and find that Chan
discloses “wherein said protected DUA and said regular DUA are both
associated with a same user.” Although the Examiner cited to Cowart in the
Final Office Action (Final Rej. 3–4), the Examiner additionally relied on
Chan for disclosing this limitation in the response to Appellant’s arguments
in the Examiner’s Answer (Ans. 7–8). We agree with the Examiner that
Chan discloses the disputed feature, and find that Cowart is merely
cumulative. Chan describes an example where
a user having an normal token with administrative privileges
may set up a system such that unless that user specifically
informs the system otherwise, the user’s processes will run with
a restricted token having no privileges. As can be appreciated,
this prevents inadvertent errors that may occur when the user is
not intentionally acting in an administrative capacity. Similarly
programs may be developed to run in different modes
Appeal 2012–002724
Application 10/456,805
8
depending on a user’s privileges, whereby an administrative-
level user has to run the program with administrative privileges
to perform some operations, but operate with reduced privileges
to perform more basic operations.

(Chan, ¶ 48). As shown here, Chan’s system allows a single user with
administrative privileges to switch between privilege levels—using either a
normal token (“regular DUA”) with administrative privileges or restricted
token (“protected DUA”) having no privileges—even while running the
same program. Appellant has not filed a Reply Brief, and thus does not
respond to the Examiner’s reliance on this disclosure in Chan (see Ans. 7–
8). Thus, absent argument or evidence to the contrary, we agree with the
Examiner and find that Chan discloses “wherein said protected DUA and
said regular DUA are both associated with a same user,” as recited in
claim 1.
Third, we also agree with the Examiner’s findings (Ans. 7–8) that
Chan discloses “wherein said protected DUA and said regular DUA . . . are
dynamically invoked based on the received content within a same user
environment of said same user, thereby enabling an integrated execution
environment for both trusted and untrusted content.” Although the
Examiner cited to Cowart in the Final Office Action (Final Rej. 3–4), the
Examiner additionally relied on Chan for disclosing this limitation in the
response to Appellant’s arguments in the Examiner’s Answer (Ans. 7–8).
We agree with the Examiner that Chan discloses the disputed feature, and
find that Cowart is merely cumulative. As discussed above, Chan discloses
switching between using a normal token (“regular DUA”) and restricted
token (“protected DUA”) while running the same program by the same user
(see Chan, ¶ 48). Further, in the example discussed above, an application
Appeal 2012–002724
Application 10/456,805
9
such as Internet Explorer “creates a restricted token from its own token” to
download and execute untrusted content (Chan, ¶ 53). One of ordinary skill
in the art would have recognized that this capability for a particular program
such as Internet Explorer to dynamically switch to a restricted token for
particular untrusted content within the same overall user account discloses a
“same user environment of said same user” and “an integrated execution
environment for both trusted and untrusted content.” Thus, absent argument
or evidence to the contrary in a Reply Brief, we agree with the Examiner and
find Chan discloses “wherein said protected DUA and said regular DUA . . .
are dynamically invoked based on the received content within a same user
environment of said same user, thereby enabling an integrated execution
environment for both trusted and untrusted content,” as recited in claim 1.
We are therefore not persuaded that the Examiner erred in rejecting
claim 1, and claims 3–6, 8–11, and 13–15 not specifically argued separately.

CONCLUSION
The Examiner did not err in rejecting claims 1, 3–6, 8–11, and 13–15
under 35 U.S.C. § 103(a).

DECISION
For the above reasons, the Examiner’s rejection of claims 1, 3–6, 8–
11, and 13–15 is affirmed.

Appeal 2012–002724
Application 10/456,805
10

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).

AFFIRMED

ELD