With respect to the '447 patent, the examiner cites to two principal items of prior art as each anticipating all of the claims of the '447 patent. In other words, the examiner has found two separate patents that establish that none of the claims of the '447 patent were novel.
With respect to the '205 patent the examiner found a single item of non-patent literature that anticipates all of the challenged claims of the patent. That is, the non-patent literature establishes that none of those five challenged claims were novel.
As we have noted before, a rejection under Sec. 102 (novelty) of the Patent Act is harder to overcome than a rejection under Sec. 103 (non-obviousness) because the latter requires both the pre-existence of the various elements of the claim and a suggestion as to why they would be combined by a person with ordinary skill in the art. Consequently, we believe the rejections in these two cases will prove to be problematic for Oracle.
Here is the updated table showing the basic stats on the Oracle reexaminations:
So far the reexaminations have been going largely in the direction Google requested, but Oracle has yet to file responses in most of the cases. In addition, the one patent involving the most challenged claims (RE38104) has yet to receive a first action on the merits.
Here is the text of the examiner's findings in rejecting the claims of the '447 patent:
Prior Art References
USPN 5,412,717 to Fischer ("Fischer" or '717) (file date 05/15/1992, issue date 05/02/1995; currently an abandoned patent), qualifies as a 35 U.S.C § 102(b) reference. USPN 5,311,591 to Fischer, a continuation of'717, was previously cited on an IDS, but never applied in a rejection of Application Control No. 08/988,439.
"The Gateway Security Model in the Java Electronic Commerce Framework" by Theodore Goldstein ("Goldstein") 11/29/1996, qualifies as a 35 U.S.C § 102(b) reference.
"Java APIs: Playing Monopoly with Java via the JECF", Rawn Shah ("Shah") 12/01/1996, qualifies as a 35 U.S.C § 102(b) reference.
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.
"The Gateway Security Model in the Java Electronic Commerce Framework" by
Theodore Goldstein ("Goldstein") 11/29/1996, qualifies as a 35 U.S.C § 102(b)
reference. Goldstein has not been previously considered.
"Java APIs: Playing Monopoly with Java via the JECF", Rawn Shah ("Shah") 12/01/1996, qualifies as a 35 U.S.C § 102(b) reference. Shah has not been previously considered.
The disclosures of Goldstein in view of Shah are not cumulative to information cited or considered during prosecution of the '447 patent.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless -
(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on sale in this country, more than one year prior to the date of application for patent in the United States.
Rejections
Claims 1-24 are rejected under 35 U.S.C. 102(b) as being anticipated by USPN 5,412,717 to Fischer. See Request 02/15/2011, pages 17-18 and Exhibit 8 Claim Chart.
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.
Per claims 2,11, and 20, Fischer discloses at least one protection domain of said one or more protection domains is associated with a code identifier.
Fischer's PAI data structure (i.e., protection domain data structure) explicitly associates the protection domain with a "source of code" such as the signer of a digital certificate. (6:25-35 & FIG. 2), "The authorization signature includes a signature segment 40. The signature segment 40 may include a reference to the signer's certificate, i.e., an identifier for identifying the signer's certificate. In accordance with a preferred embodiment of the present invention, such a digital certificate is a digital message created by a trusted entity which contains the user's public key and the name of the user (which is accurate to the entity's satisfaction) and possibly a representation of the authority which has been granted to the user by the party who signs the digital message." See also Fischer 9: 3-8, associating the PAI with the manufacturer of the program; 11: 7-13, manufacturer may define a range of authorities associated with the program; 16: 12-25, program associated with signed 'pedigree' (public key or digital certificate) from manufacturer.
Fischer discloses at least one class of said one or more classes is associated with said code identifier. See Fischer, Figures 2 and 3C. The PAI data structure may contain a manufacturer's signature (i.e., code identifier) and that the PAI with the code identifier is associated with the object/class data structure because it is expressly included as part of
the object/class data structure. Fischer, Fig. 3C ("PROGRAM(S') SIGNED
AUTHORIZATION (PAI)" included as element 116 of the disclosed object/class data
structure).
Fischer discloses associating said one or more protection domains and said one or more classes based on said code identifier.
Authorization (e.g., protection domains) may be associated with a program based on the digital signature (i.e., code identifier) included in an object/class: (16: 15-20), "Thus, if a well known manufacturer of programs has signed the program with a public key or digital certificate, then, if desired, such a program may be assigned whatever level of authority desired depending upon how much the manufacturer is trusted and the system may permit execution of such program."
Per claims 3,12, and 21, Fischer discloses the code identifier indicates a source of code used to define each class of said one or more classes.
(7: 51-56), "FIG. 3C shows an illustrative data structure for a secure exchangeable 'object'. The data structure may be signed by a trusted authority. The signing of such a data structure allows the object to be securely transmitted from user to user."
Per claims 4,13, and 22, Fischer discloses the code identifier indicates a key
associated with each class of said one or more classes. As an example, Figure 2 in
Fischer discloses the digital certificate (i.e., code identifier) includes a public key that
may be associated with the object/class. (6: 25-35), "...such a digital certificate is a
digital message created by a trusted entity which contains the user's public key and the
name of the user (which is accurate to the entity's satisfaction) and possibly a
representation of the authority which has been granted to the user by the party who signs
the digital message." Note discussion above related to an object program, where objects
are instances of a class definition.
Per claims 5,14, and 23, Fischer discloses the code identifier indicates a source of code used to define each class of said one or more classes. The digital signature (i.e., code identifier) may be associated with a manufacturer of the program (i.e., a source of code or "an entity from which computer instructions are received"): (9:3-8), "The present invention allows PAI information to be associated in any appropriate manner, so that in principle a user could define one or more levels of PAI which are then combined together with perhaps a more universal PAI, or with a PAI which was signed and supplied by the or [sic] manufacturer of this program." (11: 7-13), "FIGS. 6 through 9... a flowchart illustrating an exemplary sequence of operations of a utility program for establishing program authorization information. Such a utility program prompts a user, i.e., the end user, the user's agent, or even the manufacturer, to define a range of authorities which are associated with a program to be executed by the user's system." (16: 12-25), "If no PAI has yet been associated with the program, then a check is made to determine whether the
program has an associated signed 'pedigree' from the manufacturer (306). Thus, if a well
known manufacturer of programs has signed the program with a public key or digital
certificate, then, if desired, such a program may be assigned whatever level of authority
desired depending upon how much the manufacturer is trusted and the system may permit
execution of such program. Such a digital signature from the manufacturer can be used to
verify...."
Fischer discloses the code identifier indicates a key associated with each class of said one or more classes. For example Figure 2 in Fischer discloses the digital certificate (i.e., code identifier) includes a public key may be associated with the object/class:
(6: 25-35 & FIG. 2), "The authorization signature includes a signature segment 40. The signature segment 40 may include a reference to the signer's certificate, i.e., an identifier for identifying the signer's certificate. In accordance with a preferred embodiment of the present invention, such a digital certificate is a digital message created by a trusted entity which contains the user's public key and the name of the user (which is accurate to the entity's satisfaction) and possibly a representation of the authority which has been granted to the user by the party who signs the digital message." See FIG. 3C. Note that Fischer teaches object code (defined classes provide a template from which an object is derived / an instance of the object).
Per claims 6,15, 20, and 24, Fischer discloses associating said one or more protection
domains and said one or more classes based on data persistently stored, wherein
said data associates code identifiers with a set of one or more permissions. (6: 25-
28), "The authorization signature includes a signature segment...may include a reference to the signer's certificate, i.e., an identifier for identifying the signer's certificate... (associate code identifiers with a set of one or more permissions)" (7: 49-8: 2), "FIG. 3C shows...PAI data structure (protection domains) is associated with a program... shows an illustrative data structure for a secure exchangeable 'object' (an object instance of a defined class). The data structure may be signed (code identifier) by a trusted authority. The signing of such a data structure allows the object to be securely transmitted from user to user. Although the data structure shown in FIG. 3 is set forth in a general format, it may be structured as set forth in the inventor's copending application filed on Apr. 6, 1992 and entitled 'Method and Apparatus for Creating, Supporting and Processing a Travelling Program' (U.S. Set. No. 07/863,552.), which application is hereby expressly incorporated herein by reference." "... The program authorization information (protection domain) is embedded in a segment 116 which specifies the authorization for the object's program or programs (where objects are instances of defined classes) in a manner to be described more fully hereinafter." Alternately, Fischer discloses (7: 20-35 & FIG. 3A, #102) storing PAI information (protection domain) on a separate/remote storage device or in the same memory as the program: "...Although the program authorization information, PAI 1, is depicted as being stored in a separate memory device 100 (data persistently stored), it may, if desired, be stored in the same memory media (data persistently stored) as its associated program."
The limitations of claim 8 are a combination of limitations from claims 1-5. Mapping to Fischer 717 is noted above.
See limitations of claim 9 addressed in the similar limitations of claims 1- 6 above.
"...said one or more sources of code..." reads on Fischer's teachings of object code (classes) provided by a trusted manufacturer. The associated 'keys' are a narrower limitation than the 'code identifier' of claim 6. The digital signature keys read on the term 'code identifier' or 'keys.' See Fischer's teachings at FIG. 3A, 3C, 7: 20-8:2.
Limitations of claim 17 are variations of claims 1 and 2 addressed above. In claim 17, 'sources of code' is a broader term similar to 'one or more classes of one or more objects.' 'One or more keys' is a narrower variation of 'code identifier.' Fischer fairly discloses a trusted manufacturer source of code (object code) (16: 13-15), and associated public key or digital signature (16: 16-17) identifying the code. (16: 50-65), For a PAI that is signed and associated with a particular program, the signatures are verified (valid and trusted?) through a certificate hierarchy, (association between protection domain, one or more sources of code, and one or more keys associated...) See Fischer FIG. 2 & 6: 25-35.
See limitations of claim 18 disclosed by Fischer in the similar limitations of claims 1-6
above.
Claims 1-24 are rejected under 35 U.S.C. 102(b) as being anticipated by Goldstein with supporting evidence by Shah. See Request 02/15/2011, page 18 and Exhibit 9 Claim Chart, which are incorporated by reference.
Goldstein describes a "Gateway" extension to the Java security model, for use in the Java Electronic Commerce Framework ("JECF"). See Goldstein, at 1. According to Goldstein, an application called a "cassette" is associated with a set of permissions (protection domain) represented by "Roles (Role objects contain permissions/authorizations)." See id. at 7-8, 10, 13-14, and Figs. 1 and 5-6. Goldstein discloses (p. 13) a Java gateway security model, which includes protection domains represented by Roles. Shah clarifies that these Roles are objects that represent and/or contain specific authorizations for a set of code (cassette), as well as a digital signature (based on a public/private key pair) corresponding to the creator of the code (cassette).
"[Rjoles dictate the available resources and security levels and control [the] program's interface to the JECF code. A local (persistent) database contains these access control lists and role information. Each... cassette (program, represented in object format, object, class, package, etc.) with its specific roles (Role objects/ protection domain store permissions) must be signed by a trusted authority before use to guarantee the identity of the originator."). The Roles may be defined on a per-package basis so that any class that
is part of the package (e.g., a cassette package) is necessarily associated with the
protection domain.
See Goldstein, at 10 ("All classes in a package have access to package-private data members and methods .... Packages are a natural choice for creating a security principal."). In addition, Goldstein discloses establishing an association between the protection domain of a user's cassette with a class corresponding to a protected resource such as a JECF database. See id. at 11-12.
Shah provides supporting evidence for Goldstein's teachings of the JECF (Java Electronic Commerce Framework). See M.P.E.P. § 2131.01(111) (An extra reference or evidence can be used in an anticipation rejection to show an inherent characteristic of the concept taught by the primary reference).
Shah further clarifies that Roles contain information regarding the permissions (or authorization) of the cassette (invoking program) and that Roles are digitally signed (code identifier) by the originator of the cassette application: Shah (p. 2), "This JECF-based service can appear in the form of an...applet...(or it could be a specific Java application on your machine." "The JECF implementation architecture from Sun consists of the following components...Payment Cassettes...Service Cassettes..." Shah (p. 3), "When the applet is loaded, the Class Loader object is set to execute in a limited environment " and calling programs are checked for their digital signature for
uniqueness. When a JECF object is invoked, the invoking program or application is
checked for its role. These roles dictate the available resources and security levels and
control that program's interface to the JECF code. A local database contains these access
control lists and role information. Each Payment and Service cassette with its specific
roles must be signed by a trusted authority before use to guarantee the identity of the
originator.'' Goldstein (p. 13) discloses a Role as essentially a public and private key
pair.
It should be noted that Gong '447 defines the term 'principal' at 2: 27-30 to include "processes, objects and threads." A permission is an authorization by the computer system that allows a principal (an executing process, object or thread) to perform a particular action or function." Goldstein (p. 10) uses the term 'principal' in a different manner: "In this paper, a right is an abstract privilege. A principal uses a right. A principal can be a person, a corporation, a program, or a body of code." Goldstein at p. 11 recites, "Electronic commerce also needs the ability to delegate rights from one principal to another..."
In summary, claims 1-24 are rejected.
