Ex Parte ErlingssonDownload PDFPatent Trial and Appeal BoardAug 29, 201410456805 (P.T.A.B. Aug. 29, 2014) Copy Citation 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 Copy with citationCopy as parenthetical citation