Claim 7 and 16 are each amended by adding the following limitation:

establishing an association between said one or more protection domains and one or more sources of code, wherein the one or more sources of code is at least one of a file, a persistent object, a FLASH EPROM reader, or a set of system libraries;

Fischer discloses a method for providing computer system security, including associating protection domains with object-oriented program structures, such as classes of objects and sources of code. Fischer discloses a set of authorities (permissions) and/or restrictions stored as "program authorization information" or "PAI." (protection domains) See Fischer, at Col. 2: 16-36. The PAI is assigned to a program to be executed (associate protection domains and classes), "to thereby delineate the types of resources and functions that the program is allowed to utilize." See id. PAIs associated to called and invoked programs may be combined, as appropriate. See id. at Col. 19: 40-54. Note object oriented data structures at Fig. 3C and Col. 2: 6-9 & 7: 49 - Col. 8: 2. The PAI can be associated with a signer of a digital certificate (see Fischer, at Col. 6: 25-35 and Fig. 2) or a manufacturer of a program (indicates the source of code used) (see Fischer, at Col. 9: 3-8 and Col. 16: 12-25). Fischer checks the PAI for authorization (determining whether said action is authorized); the PAI of Fischer may include a "hierarchy of nested certifications and signatures" (permissions associated with a plurality of routines in a calling hierarchy). USPN 4,868,877 and USPN 5,005,200, which are incorporated by reference, disclose additional teachings related to digital certificates and signatures.

Per claims 1, 7,10,16, and 19, Fischer '717 discloses a method, computer readable medium executed by one or more processors, and system for providing security.

The Fischer disclosure references 'authorization entries' within the "program authorization information," or "PAI," to verify access authority to other code and resources. "... providing enhanced computer system security while processing computer programs... " Fischer at 1:20-25. See exemplary computer readable medium carrying a "sequence of instructions" as shown in Fischer '717, FIGs. 1 (#2, #7), 10 & 11. Fischer '717 teaches (Abstract; 4: 24-61) a system.

Fischer discloses establishing one or more protection domains, wherein a protection domain is associated with zero or more permissions;
Fischer's PAI ('717, 2: 34-36) reads on the claimed 'protection domain.' (2: 20-23), "The system monitor builds a data structure (establishing one or more protection domains) including a set of authorities (protection domains as PAIs defining permissions) defining that which a program is permitted to do (permissions) and/or that which the program is precluded from doing." (9: 17-10: 23), "The program control block 140 is loaded with program authorization information such that the PAI can be readily referenced as the associated program is executed so as to ensure that the program performs functions and accesses resources in conformance with its assigned authorizations. The program control block associated with the program to be executed is located in a storage area which cannot be modified by the program."

Fischer discloses establishing an association between said one or more protection domains and one or more classes of one or more objects.
(2: 6-9), "The present invention is directed to providing reliable security, even when operating with complex data structures, e.g., objects, containing their own program instructions, which are transmitted among users." (2: 26-33), "Once defined, the program authorization information [(PAI)] is thereafter associated with each program to be executed to thereby delineate the types of resources and functions that the program is allowed to utilize. The PAI associated with a particular program may be assigned by a computer system owner/user or by someone who the computer system owner/user implicitly trusts." See Fischer, FIG. 3C, #116, noting an object oriented program. An object is an instance of a class, i.e., a class template. Gong '447 recites (6: 63-7: 29) well known facts related to objects: "[e]ach object belonging to a class has the same fields ('attributes') (protection domain attributes) and the same methods." (7: 14-18, 7: 49-8: 2), "... The program authorization information is embedded in a segment 116 which specifies the authorization for the object's program or programs in a manner to be described more fully hereinafter." (15: 24-26), "Thereafter, the PAI is stored using, for example, one of the approaches set forth in FIGS. 3A through 3D so that it is associated with its program 272 ...."

Fischer discloses determining whether an action requested by a particular object is permitted based on said association between said one or more protection domains and said one or more classes.
(15: 56-59), "FIGS. 10 and 11 illustrate the sequence of operations of a supervisor program for controlling the processing of a program being executed in accordance with its program authorization information." (16: 66-17: 3), "Depending on the processing in block 316 [of FIG. 10], a decision is made in block 322 whether the signatures are valid, authorized and trusted. If the signatures are not determined to be valid, then the routing branches to block 324 where the execution in program X is suppressed." In the case where digital signatures are used to determine whether an action requested is permitted, Fischer discloses (17: 31-33), "If the processing in blocks 322 and 316 reveal that the signatures are valid, then the processing in block 326 is performed." As noted above, the protection domain objects are derived from (association) a protection domain class definition.

Claim 19 also recites the term "domain mapping object" for establishing an association between said one or more protection domains and one or more classes of one or more objects. Fischer discloses (2: 20-23), "The system monitor (domain mapping object) builds a data structure (establishing an association between one or more protection domains) including a set of authorities (protection domains as PAIs defining permissions) defining that which a program is permitted to do (permissions) and/or that which the program is precluded from doing." (FIG. 3C; 7: 14-18, 7: 49-8: 44), The data structure defines (establishes associations) the type of object...embeds a segment with program authorization information, a segment with object method code, and a segment with data variables.

Oracle, in its response, acknowledges that the critical elements comprising the invention are those cited by the examiner:

■ establishing one or more protection domains, wherein a protection domain is associated with zero or more permissions;
■ establishing an association between said one or more protection domains and one or more classes of one or more objects; and
■ determining whether an action requested by a particular object is permitted based on said association between said one or more protection domains and said one or more classes.

The art of the present reexamination does not compel a different conclusion. None of the cited references—Fischer, Goldstein, or Shah—teaches or suggests the above claimed combination of features of the '447 Patent. Fischer does not disclose "establishing an association between ... protection domains and ... classes." Instead, Fischer is directed to providing security by associating program authorization information ("PAI") with a program. Fischer is silent as to classes or any security based on classes. Indeed, the lack of any discussion as to classes in Fischer is dispositive not only with respect to the above "establishing" feature, but also to the other features such as "determining whether an action requested by a particular object is permitted based on said association between ... protection domains and ... classes."

establishing an association between ... protection domains and ... classes" because both Goldstein and Shah, similarly to Fischer, are silent as to any security based on classes.

Accordingly, Patent Owner submits that all of the rejections should be withdrawn.

* * * *

Claim 1 recites, inter alia:

"establishing an association between said one or more protection domains and one or more classes of one or more objects."

The Office Action (p. 12) asserts that Fischer discloses this claim feature in a "set of authorities and/or restrictions assigned to a program to be executed are referred to herein as 'program authorization information' (or 'PAI')." (Fischer, 2:24-26.) Patent Owner respectfully disagrees with this assertion.

Fischer teaches a security monitor that limits the ability of a program about to be executed to the use of predefined resources through the use of the PAI. Fischer envisions the program, to which the PAI is assigned, as a virus program (Fischer, 1:30-31), a game (Fischer, 9:29-30), or the like. A program, however, is most certainly not a class. According to Prof. Goldberg's declaration, "a program in an object-oriented language (e.g. Java and C++) may include classes, whereas a program in a non object-oriented language (e.g. C, Lisp, assembly language, etc.) would not be considered to include classes." (Emphasis added; Goldberg Declaration, 111.) Thus, Fischer's programs do not disclose "one or more classes of one or more objects" as expressly required by the claims.

Further, Fischer's provision of security at a program-level is also insufficient. "In Fischer, every portion of the program - including the classes if the program is written in an object-oriented language - would have the same permissions. Thus, even in an object-oriented language, Fischer does not provide a mechanism for associating different permissions with different portions of code within the same program." (Goldberg Declaration, 111.) Because Fischer does not teach anything related to classes, it cannot disclose that the PAI is associated with "one or more classes of one or more objects." Therefore, claim 1 is not anticipated by Fischer.

In the Office Action and during the interview, the Examiner viewed the program in Fischer as having classes and inquired that, if Fischer disclosed a program with classes, whether the association of the PAI with a program having classes would meet the above feature if construed broadly. It is believed that the Examiner was trying to abstract an object-oriented implementation from Fischer based on Fischer's Fig. 3C. Even if Fischer disclosed a program with classes, which it does not (Goldberg Declaration, 111), the feature would still not be met, as the Patent Office's proposed construction is not supported by the claim language nor is it consistent with the '447 specification, as noted by Prof. Goldberg during the interview. The claim language—"establishing an association between ... protection domains and ... classes"—expressly links the protection domain to classes, not programs. The link between protection domains and classes was emphasized in the '447 specification as providing a finer level of granularity for establishing protections within a computing system than at the entire program level (i.e., at the level that Fischer discusses). (Goldberg Declaration, 112.) For example, the specification states that the "sandbox approach is not very granular because all remote code is restricted to the same limited set of resources." ('447, 2:11-13.)

It is undesirable to choose a coarser level of granularity, such as "all remote code" or an entire program such as the one described in Fischer, because this limits the flexibility of the code to be assigned varying permissions. According to Prof. Goldberg's declaration, "[c]hoosing a coarser level of granularity than associating permissions with classes, such as associating the same permissions with 'all remote code' (i.e. all code loaded from remote sources) as in the prior art Java 'sandbox' model, or associating permissions with an entire program as in Fischer, limits the flexibility of the code to be assigned varying permissions. For example, since Java programs are often constructed from classes retrieved from multiple sources - some of the sources more trusted than others - it is desirable to be able to assign different permissions to the classes retrieved from different sources." (Goldberg Declaration, 112.) All remote code, or all code within a program, is assigned the same permissions, regardless of trustworthiness of the various components. However, "[providing security measures that allow more granularity than the sand box method involves establishing a complex set of relationships between principals and permissions." ('447, 2:24-26.) "In Fischer, however, all code within a program is assigned the same permissions, regardless of trustworthiness of the various components. The claimed invention of the '447 Patent solves these problems by providing a more granular level of protection (i.e., associating protection with classes) and simplifying the relationships between principals and permissions via the protection domain mechanism. In fact, Fischer teaches away from using class-level protection by teaching program-level protection." (Goldberg Declaration, 113.) '"Teaching away' does not require that the prior art foresaw the specific invention that was later made, and warned against taking that path." Spectralytics, Inc., v. Cordis Corp. (Fed. Cir. June 13, 2011). Rather, the design of the prior art device itself can teach away from the invention. (Id.) Here, the design of Fischer (i.e., protection associated at the program level) teaches away from the claimed "establishing an association between ... protection domains and ... classes" of the '447 Patent.

Moreover, upon reading the specification, one of skill in the art would recognize that the "association" in "establishing an association between ... protection domains and ... classes" requires the protection domains to be associated with classes, not with programs. (Goldberg Declaration, 114.) See, e.g., '447, 2:10-22 (where in the background art, sets of files are "associated" with particular banks), and contrast with examples described at '447, 2:50-3:50 (where protection domains are "associated" classes and permissions), 6:65-66 (where methods are "associated" with objects), etc. In each of the examples from the '447 specification, "associated" means that the two pieces are associated with each other, not associated through another construct, such as a program. One of skill in the art could not interpret the claimed "association" differently because none of the examples provided in the specification suggest otherwise. (Goldberg Declaration, 114.) Indeed, to adopt such a construction would directly contravene the requirement of giving claims their "broadest reasonable construction consistent with the specification" in a reexamination. (MPEP 2258(I)(G) (emphasis added); In re Suitco Surface, 603 F.3d 1255, 1259 (Fed. Cir. 2010). In contrast, construing the feature as associating protection domains with classes would be consistent with the specification, as the entire patent teaches such an association.

(Goldberg Declaration, 114.) According to Prof. Goldberg's declaration, "[o]ne of ordinary skill in the art reading the '447 patent would understand the "association" between classes and protection domains to be any mechanism that allows the code from different classes within the same program to operate with different protection domains. Fischer's disclosure of associating a PAI with a program does not provide such a mechanism." (Goldberg Declaration, 114.) Therefore, one of skill in the art would recognize that associating a PAI with a program does not disclose "establishing an association between ... protection domains and ... classes," as recited in claims 1, 10, and 19.

When discussing Fischer, the Office Action cites to the disclosure at ('447, 7:4-6), that each object belonging to a class has the same fields and the same methods, to conclude that protection domain attributes may be stored in the fields of an object instantiated from that class. (Office Action, page 12.) However, at the time of invention, while programs as a whole may generally have had protection attributes as shown by Fischer, protection was not provided on a class by class basis. (Goldberg Declaration, 114.) Accordingly, although the fields of objects instantiated from the same class were the same, the fields of a class did not have protection domain attributes.

For at least this reason and the reasons discussed above, Fischer does not teach or suggest "establishing an association between one or more protection domains and one or more classes of one or more objects," as claimed in independent claims 1,10, and 19.

This is a fairly compelling argument, and one to which the examiner will need to dig deep to counter. Oracle argues much this same point with respect to Goldstein as it does above with respect to Fischer.

It is also worth remembering that this is an ex parte reexamination, so Google does not have a right to respond to Oracle. In any case, Fischer, Goldstein, and Shah are the only prior art that Google submitted.

Now we wait to see how the examiner responds.