For those of you wishing to keep score, here is a table showing the Oracle claims asserted against Google, the number of those claims that are not presently subject to reexamination (and thus still enforceable), the number subject to reexamination, the number of those subject to reexamination that are subject to a USPTO rejection, and the number of claims still surviving.
Prior Art References
USPN 5,412,717 to Fischer, entitled "Computer System Security Method And Apparatus Having Program Authorization Information Data Structures," file date 05/15/1992, issue date 05/02/1995 (hereinafter "Fischer" or 717), qualifies as a 102(b) reference. [USPN 5,412,717 to Fischer is an abandoned patent. USPN 5,311,591 to Fischer, a continuation of'717, was used in the original prosecution of the Gong '431 Patent Application.]
Fischer '717 is proposed as prior art in this reexamination, citing to different teachings within the Specification. Fischer notes that a request for an action made by a 'routine' associated with the top of the stack (to load or otherwise invoke a subsequent routine) is based on permissions associated with a plurality of routines in a calling hierarchy, i.e. the permissions /authorizing information / aggregated constraints associated with a plurality of routines, whose associated
'program control blocks' (PCBs) are hierarchically placed on the call stack (routines in a calling
hierarchy), as noted at '717, 17: 40-51. Fischer ('717, 2: 6-9) "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."
Applicant's summary of an interview held 05/11/2000 during prosecution of application 08/988,431 (Request for Reconsideration, 05/16/22000, p. 2) noted, "That is, the "request" of Fischer '591 does not properly map to "a routine in a calling hierarchy" as argued in the final Office Action (final Office Action, page 4). Furthermore, since the claims actually recite "a plurality of routines" (emphasis provided), the single "request" of Fischer would not properly be mapped to the "plurality of routines" recited in the claims, in any case."
The Gong '476 Specification recites ('717, 3: 7-10), "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." In other words, when a calling hierarchy is present on the call stack of a principal, the access rights of the principal depend on the source of the code on the call stack; because the source of the code on the call stack will vary, as certain code is implemented and then exited, the access rights of the principal will vary as well. (See Gong '476, Abstract.)
Third Party Requester cites to Fischer in a new light. Fischer discloses ('717, 10: 24-26) "an
originating program" that "calls a program" where the calling program has a program control
block, or PCB on the call stack. Each called and subsequently invoked program has an
associated program control block on the call stack. The program control block ('717, 10: 11-14)
"is the data structure utilized by the system monitor to control the execution of an associated
program." Fischer clearly discloses ('717, 10: 23-25) a hierarchy of programs: "an originating
program.., calls a program (having a PCB 170) which will, in turn [] call the program 140."
Associated with this hierarchy ('717, 10: 26-28), "each new PCB will include a field such as 150
that points to the 'previous' or calling program control block." Thus, the hierarchy of programs
has an associated hierarchy of program control blocks, each associated with varying program
authorization information (PAI). PAIs associated with the call stack are aggregated. Once the
('717, 10: 31-36) "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."
In an alternate teaching, the Fischer '717 reference incorporates by reference two patents, USPN 4,868,877 to Fischer and USPN 5,005,200 to Fischer, which disclose (USPN 5005,200, Abstract) an "enhanced digital signature certification" which employs "[a] hierarchy of nested certifications and signatures." This examination of the hierarchy of nested certifications and signatures is linked to an associated hierarchy of programs that carries the certifications and signatures in question. In other words, Fischer discloses in one embodiment an "originating program" that "calls a program" (a request); when, and each time, a program call is made,
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). Thus, the Fischer reference
discloses permissions "associated with a plurality of routines in a calling hierarchy."
Consideration of teachings found at 10: 23-36 and in the '877 and '200 patents, which are
incorporated by reference, present Fischer in a new light.
Elliott I. Organick, "The Multics System: An Examination of Its Structure", 1972 (hereinafter "Organick"), qualifies as a 102(b) reference.
Organick discloses the "Multics" software system, with internal security control components. The Multics system employs a "ring structure" to achieve the controlled sharing of information. See Organick at p. xvi. The Multics system used access controls along with the ring structure to allow for multi-level permission: "access control and ring brackets ... are fundamental to the system of protection and to the controlled sharing of data and procedures in Multics." See Organick at p. 133. The Multics system will first implement its security system upon the detection of a request: "[R]ing compartmentalization is carried out with some hardware aid. Multics exploits special GE 645 fault-detection hardware to detect and trap a process whenever it attempts to make a cross-ring reference, in order to invoke the intervention of supervisory software." See Organick at p. 133. Once the request is detected, the Multics system will implement its supervisory software. This software will allow some actions and disallow certain other actions.
USPN 5,958,050 to Griffin et al., entitled "Trusted Delegation System," file date 12/26/1996,
issue date 09/28/1999 (hereinafter "Griffin" or '050), qualifies as prior art under 102(e).
The Griffin reference discloses (1: 22-25) a method for the "management of trust relationships among code segments to be executed inside a trust boundary." Griffin discloses (1: 23-25) a security management program, or trust management system, "for management of trust relationships among code segments to be executed inside a trust boundary." More specifically, the system disclosed by Griffin is directed to (3: 26-29) "an improved trust management system.., where trust in program code can be varied for a user given the user's particular circumstances and the source of the program code."
Griffin discloses (FIG. 3) the receipt of code from a source that may be outside of a user's "trust boundary." A "code identifier" then analyzes the code and determines "whether execution of the portion of code is allowed by the policy rules given the potential resource use." See id., at Abstract. The code analyzer of Griffin employs a set of permissions- what it calls certificates or policies—which are granted to one or more principals; these "[certificates and policies can be specified in hierarchical form, so that some levels of security can be delegated to trusted entities." See id. These certificates and policies, specifically disclosed here in hierarchical form, correspond directly to the protection domains and permissions of the '476 patent.
In other words, Griffin discloses that "[i]f it is determined that clearance to trust is required to grant a particular access, a path of trust must be found before the access will be granted by the trust manager," (detecting a request); Griffin then employs a "trust manager" that "examines each new class before it is allowed to load," (determining whether the action is authorized). Griffin also discloses that "[certificates and policies can be specified in hierarchical form, so that some
levels of security can be delegated to trusted entities." See id. at Abstract.
Patrick Chan, "The Java Class Libraries An Annotated Reference", 09/1996 (hereinafter "Chan"), qualifies as prior art under 102(b).
Chan discloses (p. 1188) that "[a] security manager enforces security policies related to what a program is allowed to do." Chan deploys its security management system by,- in part, referencing the source of the code currently being executed on the stack. For example, Chan discloses (p. 1189) certain "Execution Stack Information," whereby "[t]he execution stack (maps to the term 'call stack') is a record of the method calls that were made from the main program to the current method." This execution stack "indicates all the methods that are in progress and pending termination of the current method call." See id.
More specifically, consider an exemplary embodiment disclosed by Chan: "For example, if main() calls foo() which in turn calls bar(), the execution stack when executing inside bar() would be bar() -> foo() -> main(). For some methods to perform some of the permission checking, they may need to inspect the execution stack to find out information about the current execution context. The SecurityManager class provides protected methods that can be used by subclasses of the SecurityManager for this purpose." See Chan at p. 1189. Chan, in response to detecting a request from a method currently on the execution stack, determines whether the requested action is authorized based on the permissions associated with the cascading hierarchy of calls. Chan discloses the application of a similar security program to an "execution stack."
A procedure that is assigned the category of ring r is privileged during its execution to call (or to reference) any procedure (or data) segment in ring r or in any ring peripheral to, that is "outside of ring r. Conversely, a procedure of ring r is prevented from referencing data segments in a more "privileged," that is, "inner" ring and is permitted call access to more privileged procedures only through specially controlled entry points called "gates." See Organick at p. 130.
Organick clearly discloses a set of permissions that are based on a multitude or plurality of routines, i.e., procedures that are assigned to rings, in a calling hierarchy. The rings of Organick correspond directly to the "protection domains and permissions" of the '476 patent. For example: "The segments of any one process are associated with a set of generally two, but possibly more, concentric rings." See id. (emphasis added). Organick discloses "up to 64 rings," wherein the rings are associated with fault-inducing bit patterns that may allow or deny access depending on the function or access level sought, i.e., permissions. See id. at p. 153.
In other words, Organick discloses "fault-detection hardware to detect and trap a process whenever it attempts to make a cross-ring reference," (detecting a request); Organick then discloses referencing the ring level permission of the procedure (determining whether an action is authorized); wherein the supervisory software of Organick references "two, but possibly more, concentric rings" (permissions...) associated with the variable number of related "segments of any one process," (... associated with a plurality of routines in a calling hierarchy)
with explicit reference to a calling hierarchy by way of the following disclosure: "if main() calls
fooO, which in turn calls bar()," (permissions associated with a plurality of routines in a calling hierarchy).
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.
Claim Rejections - 35 USC $ 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459
(1966), that are applied for establishing a background for determining obviousness under 35
U.S.C. 103(a) are summarized as follows:
A) Determining the scope and contents of the prior art.
B) Ascertaining the differences between the prior art and the claims at issue.
C) Resolving the level of ordinary skill in the pertinent art.
D) Considering objective evidence present in the application indicating obviousness or nonobviousness.
Rejections
Claims 1-7,10-16, and 19-21 are rejected under 35 U.S.C. 102(b) as being anticipated by USPN 5,412,717 to Fischer. See Request 01/10/2011, pages 16-18 and Exhibit 10 Claim Chart.
Claims 8-9 and 17-18 are not included in the anticipation rejection. Fischer does not disclose the step of setting a flag associated with said first routine to indicate that said first routine is privileged. Fischer does not teach a flag field.
Gong '476 describes a flag at FIG. 3 and 3: 33-40, "A privileged routine is allowed to perform certain actions even if the routine that called the privileged routine does not have permission to perform those same actions...a flag in a frame in the calling hierarchy corresponding to a privileged routine is set to indicate that the privileged routine is privileged..." Also see Gong '476, 14: 56,- 15: 14, "One technique to track which invocation of a particular method are enabling invocations is to set a flag (privilege flag 312) in the frame 310 corresponding to each enabling invocation...each frame has a privilege flag value..."
See Gong '476 3: 33-41, "...certain routines may be 'privileged'. A privileged routine is allowed
to perform certain actions even if the routine that called the privileged routine does not have
permission to perform those same actions...a flag in a frame in the calling hierarchy
corresponding to a privileged routine is set to indicate that the privileged routine is privileged."
While Fischer '717 does recite (12: 58-65), "The present invention, while it primarily focuses on defining functions which restrict the ability of a program to access...could also...be used to extend the capabilities beyond those normally allowed...could be allowed to perform extended functions (privileged routines)." Fischer (10:47-49) discloses the field 156 of the program control block identifies the location in storage (157) of one or more the PAIs... Examiner asserts that such a location pointer does not function as would the "flag" of the instant limitation.
Per claim 1, Fischer discloses a method 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.
Fischer discloses detecting when a request for an action is made by a principal.
Gong '476 describes a 'principal' at 2: 37-39, "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." 3: 67-3:2, "...access rights for a principal are determined dynamically based on the source of the code that is currently being executed by the principal (e.g., thread, process).
Broadly a 'principal' reads on Fischer's 'system monitor' (2: 17-18) which limits the ability of a program to be executed. See 10: 10-13, "The program control block 140 is the data structure utilized by the system monitor to control the execution of an associated program. Fischer (15: 56-58) also uses the term 'supervisor program' for controlling the processing of a program being executed.
See FIG. 10 (#300, call program X). Fischer inquires into the permissions of a given principal's PAI upon the principal's request for an action: "When the program is to perform a function or access a resource (detecting when request for action is made), the associated PAI (PAI associated with the calling program) is monitored to confirm that the operation is within the defined program limits. If the program (calling program) attempts to do anything outside the authorized limits, then the program execution is halted." Id. at 2:43-48.
Fischer (2: 24-31; 7: 14-15), "The set of authorities and/or restrictions assigned to a program to be executed are referred to herein as "program authorization information" (or "PAI")...thereafter associated with each program to be executed."
Fischer discloses a "program" that executes "operations" (2: 35) or performs a "function (2: 43-
44) (by way of a thread of execution / a 'principal')." Fischer discloses the program as part of
data objects (object oriented language, where instances of a class are instantiated as an object;
See 4: 11, object oriented). Fischer discloses (10: 3-57) a program ("originating program") that
calls a second "program." The second program, in turn calls a third program, such that called
programs are hierarchically executed. Each program, the 'originating program' or authorized
subsequently called program, places a 'program control block' (PCB) (10: 36-37) on the
execution stack (stack/call stack; load program X), following a 'yes' exit from #322 or #320.
Fischer discloses in response to detecting the request, determining whether said action is authorized based on permissions associated with a plurality 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.
(9: 58-63), "After the PAI has been assigned, any time the system runs the associated program (by the principal), the system software...ensures that the program safely runs in a manner consistent with the PAI. Thus, the program has been effectively placed in a 'safety box' (124)." (determining whether said action is authorized based on permissions...) (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." (15: 56- 16: 2), "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. The processing of a program
'X' and its program authorization information illustrated in FIG. 10 is initiated while the
computer is executing a supervisor routine (supervisor program executing supervisor routine,
i.e., principal, controls the processing of a called program 'X', i.e., nested programs / calling
hierarchy). As shown in FIG. 10 at 300, a calling program calls program 'X' for execution (i.e.,
supervisor program calls program 'X'). Thereafter, a program control block is created for
program X. The program control block created will not be added to the top of the execution
stack until it is determined that the program is permitted to be invoked and verification is
successful completed (permissions associated with routines of calling program based on PAI
defined for the calling program and permissions/ authorization entries defined within the PAI.
See 'authorization entries' of PAI at 5: 55- 61) Thus, if the program fails a security check, it will
not be placed in the program execution chain." (emphasis added)
The term 'protection domains' is defined by Gong '476 at 8: 55-64, "...protection domains are used to enforce security within computer systems. A protection domain can be viewed as a set of permissions granted to one or more principals. A permission is an authorization by the computer system that allows a principal to execute a particular action or function...permissions involve an authorization to perform an access to a computer resource..." Broadly Fischer's PAI ('717, 2: 34-36) is reads on the claimed 'protection domain.'
Fischer also incorporates by reference (6: 37) two patents which disclose data hierarchies:
USPN 4,868,877 and USPN 5,005,200. The two patents disclose an enhanced digital signature
certification which employs a "hierarchy of nested certifications and signatures" which fairly
reads on a calling hierarchy (nested certificate hierarchy must be examined for permissions)
associated with said principal.
Fischer discloses ('717, 6: 25-58) the association between permissions and the plurality of routines based on a first association between protection domains and permissions. See
'877, 13: 50-51, hierarchy of authority; '877, 15: 18-20, hierarchy of all certificates; '877, 17: 26-27, authorized by antecedent certificates. See '200, 7:3-7, certificates created convey authorizations, restrictions; '200, 7: 17-18, hierarchically derived certificates; '200, 10: 50-67, digital signature accompanied by at least one valid certificate, may be associated with one or more other valid certificates hereinafter referred to as antecedents to that certificate; '200,20: 10-12, B's signature and the hierarchy of all certificates and signatures which validate it are kept by A and sent along whenever A uses this certificate; '200, 22: 17-23, all certificates must be accompanied by signatures which themselves are authorized by antecedent certificates. The digital certificates and signatures take into account permissions of programs other that 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 require consideration of permissions associated with a plurality of routines in the calling hierarchy of the digital signature / certificate authorizations.
It is noted that for the purpose of reexamination the term 'routine' includes within its scope such terms as function, operation, program, method, or the concept of "access" to a resource.
Per claim 2, Fischer discloses the step of detecting when a request for an action is made includes detecting when a request for an action is made by a thread. Fischer's invention inquires into the permissions of a given principal's PAI upon the principal's request for an action: "When the program is to perform a function or access a resource, the associated PAI is monitored to confirm that the operation is within the defined program limits. If the program attempts to do anything outside the authorized limits, then the program execution (thread of execution) is halted." Id. at 2:43-48. See FIGs 3A - 3D, describing authorizations found in PAIs associated with programs to be executed by thread.
See Gong '476, 2: 36- 3: 2, "A 'principal' is an entity in the computer system to which permissions are granted...principals include processes, objects, and threads." The 'principal' performs actions or functions (i.e., code is executed by the 'principal').
See FIG. 10, #300 Call Program X and '717, 15: 56-63. At this point the request for an action by the executing thread is detected. A supervisor program for controlling the processing of a program being executed, executing its supervisor routine (thread of execution), detects a call to program X (detects an action).
Fischer discloses the step of determining whether said action is authorized includes determining whether said action is authorized based on an association between permissions and a plurality of routines in a calling hierarchy associated with said thread.
Fischer discloses determining whether said action is authorized includes determining whether said action is authorized based on an association between permissions and a plurality of routines in a calling hierarchy in view of associating permissions by aggregating constraints of PAIs associated with program control blocks on the execution / call stack or by associating with the nested certifications and signature routines in a calling hierarchy associated with a thread, as taught by USPN 4,868,877 and USPN 5,005,200.
See Fischer FIG. 5 and 10: 24-26, "FIG. 5 is an illustration of a program control block (PCB) data structure 140 in accordance with an exemplary embodiment of the present invention. The program control block 140 is the data structure utilized by the system monitor to control the execution of an associated program.
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.
As shown in FIG. 5, an originating program (whose PCB is identified at 180) calls a
program (having a PCB 170) which will, in turn, will call the program 140 is shown in detail
in FIG. 5. Each new PCB will include a field such as 150 that points to the 'previous' or
calling program control block. A field may also be utilized to identify the 'next' program
control block file.
"Thereafter, the program X's program authorizing information is combined, as appropriate, with the PAI associated with the PCB of the calling program (association between permissions and a plurality of routines in a calling hierarchy associated with said thread), if any. This combined PAI, which may include multiple PAIs, is then stored in an area of storage which cannot generally be modified by the program and the address of the PAI is stored in the process control block (PCB) as indicated in field 156 of FIG. 5. Thus, if program X is called by a calling program, it is subject to all its own constraints as well as being combined in some way with the constraints of the calling program, which aggregate constraints are embodied into program X's PAI (determine whether action is authorized). In this fashion, a calling program may not be permitted to exceed its assigned bounds by merely calling another program. There are many alternative ways that a program's PAI could be combined with the PAI of the program which invokes it—depending on the strategies which are applicable to the current environment, and the inherent nature of the programs themselves. It may even be likely that even the method of combination is itself one of the PAI authorities, or qualifiers, of either or both the invoking or invoked program.
For example, it is reasonable to restrict a called program to the lesser of its 'normal' PAI
authority and that of its calling program—to ensure the calling program cannot mischievously
misuse the called program's greater authority to circumvent its own limitations.
On the other hand, for called programs which carefully verify their own actions, it could be possible to allow the called program greater inherent authority than the program which calls it—this way sensitive resources could be made available to wider use by mediating such use through trusted sub-programs. The possibilities for such combination must be carefully considered, not only by the designers of the underlying control system, but also by those who assign authority to each program. Thereafter, the program is loaded and the hash of the program is computed based on the algorithm specified in the program's PAI." Fischer at 17:40-18:10. (emphasis added)
Alternately, consider Fischer's incorporation by reference (Fischer '717, 6:37) of two patents which explicitly disclose data calling hierarchies: USPN 4,868,877 and USPN 5,005,200. See USPN 5,005,200, Abstract, for disclosure of an "enhanced digital signature certification" employing "[a] hierarchy of nested certifications and signatures." The '877 and '200 patents disclose a plurality of routines in a calling hierarchy associated with a thread. An examination of the nested certificates determines whether the action is authorized.
Per claim 3, Fischer discloses the calling hierarchy includes a first routine. For example, Fischer discloses (10: 24-27) calling a plurality of routines: "As shown in FIG. 5, an originating
program (whose PCB is identified at 180) (first routine) calls a program (having a PCB 170)
which will, in turn, will call the program 140 is shown in detail in FIG. 5." The called programs
associated with PCBs 180, 170, and 140 are representative of the calling hierarchy.
Fischer discloses the step of determining whether said action is authorized further includes determining whether a permission required to perform said action is encompassed by at least one permission associated with said first routine. Fischer utilizes the PAI data structure associated with a program to determine whether the requested action is authorized. The data structure includes a header segment 114 which, by way of example only, may define the type of object that follows, e.g., a purchase order related object or any other type of electronic digital object. 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." Fischer at 7:49-8:2. "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. The processing of a program 'X' and its program authorization information illustrated in FIG. 10 is initiated while the computer is executing a supervisor routine. As shown in FIG. 10 at 300, a calling program calls program X for execution. Thereafter, a program control block is created for program X. The program control block created will not be added to the top of the execution stack until it is determined that the program is permitted to be invoked and verification is successful completed (determining whether said action is authorized). Thus, if the program fails a security check, it will not be placed in the program execution chain (will not be invoked / placed on the call stack). In addition
to creating a 'tentative' program control block, the called program will be located through an
appropriate program directory during the processing in block 302.
See FIG. 10 and steps between calling the program at #300 and invoking / loading the 'authorized' program onto the call stack (i.e., steps #302-#322 determine whether a permission required to perform said action is encompassed by at least one permission associated with said first routine).
Per claim 4, Fischer discloses the step of determining whether said action is authorized further includes determining whether a permission required to perform said action is encompassed by at least one permission associated with each routine in said calling hierarchy.
Fischer discloses (17: 40-51) an embodiment wherein PAI information is aggregated, and access is determined based on this aggregated grouping. See FIG. 5. An executing program is aware of the hierarchy of calling programs (i.e., program 180 calls program 170, which calls program 140, etc). Pointer fields (FIG. 5, #150) in each PCB of the execution stack are aware of the 'previous' or calling program control block and may also be utilized to identify the 'next' program control block file. Fischer at 10:23-39. "There are many alternative ways that a program's PAI could be combined with the PAI of the program which invokes it—depending on the strategies which are applicable to the current environment, and the inherent nature of the programs themselves. It may even be likely that even the method of combination is itself one of the PAI authorities, or qualifiers, of either or both the invoking or invoked program. For example, it is reasonable to
restrict a called program to the lesser of its 'normal' PAI authority and that of its calling program-
-to ensure the calling program cannot mischievously misuse the called program's greater
authority to circumvent its own limitations. On the other hand, for called programs which
carefully verify their own actions, it could be possible to allow the called program greater
inherent authority than the program which calls it—this way sensitive resources could be made
available to wider use by mediating such use through trusted sub-programs. The possibilities for
such combination must be carefully considered, not only by the designers of the underlying
control system, but also by those who assign authority to each program. Thereafter, the program
is loaded and the hash of the program is computed based on the algorithm specified in the
program's PAI." Fischer at 17:40-18:10.
Per claim 5, Fischer discloses a method for providing security. The Fischer disclosure employs "program authorization information," or "PAI," to limit a principal's access authority to other code and resources. "More particularly, the invention relates to a method and apparatus for providing enhanced computer system security while processing computer programs, particularly those of unknown origin, which are transmitted among users." Fischer at 1:20-25.
Fischer discloses detecting when a request for an action is made by a principal. Fischer inquires into the permissions of a given principal's PAI upon detecting the principal's request for an action: "When the program is to perform a function or access a resource (when request for an
action is detected), the associated PAI is monitored to confirm that the operation is within the
defined program limits. If the program attempts to do anything outside the authorized limits, then
the program execution is halted." Id. at 2: 43-48.
"FIGS. 10 and 11 illustrate the sequence of operations of a supervisor program (principal thread of execution) for controlling the processing of a program being executed in accordance with its program authorization information. The processing of a program 'X' and its program authorization information illustrated in FIG. 10 is initiated while the computer is executing a supervisor routine (principal). Fischer at 15: 56-16: 11.
Fischer discloses determining whether said action is authorized based on an association between permissions and a plurality of routines in a calling hierarchy associated with said principal. Fischer discloses "an originating program" that "calls a program" having a program control block, or PCB. Fischer at 10: 24-26; 10: 8-39; FIG. 5. "Each new PCB will include a field... that points to the 'previous' of calling program control block." See id. at 10: 27-29. Fischer also notes (FIG. 10; 15: 56-59) the sequence of operations done by a "supervisor program (principal) for controlling the processing of a program being executed in accordance with its program authorization information." The steps of FIG. 10 prior to step 326 relate to "determining whether said action is authorized." If authorization is determined, the called program is loaded (invoked) onto the call stack at #326. A plurality of routines in a calling hierarchy are added to the top of the call stack (routines in a calling hierarchy associated with
said principal; 16: 1-2, "placed in the program execution chain") and each routine is associated
with permissions defined in its PAL As an added routine completes its execution, it is removed
from the call stack, and subsequently called routines will be placed on the call stack. Then,
"[w]hen a called program finishes executing, the system removes its associated PCB from the top
of the executed stack (call stack), removes the associated program from storage, removes the
associated authorizing information and accesses the program control block immediately below it
in the stack (call stack)." See id. at 10:31-36. See PAIs defined at 2: 16-48. PAI authorizing
information of the program at the top of the call stack may be combined with the PAI associated
with the program control block (PCB) of the calling program, or of multiple PAIs on the call
stack. Aggregated constraints found in PAI at top of call stack provide an association between
permissions and a plurality of routines. See id. at 17:40-56.
Fischer also incorporates by reference two patents which explicitly disclose data hierarchies. See id. at 6:37; 16: 12-65 (incorporating by reference U.S. Patent Nos. 4,868,877 and 5,005,200 disclosing an "enhanced digital signature certification" which employs "[a] hierarchy of nested certificates and signatures (trust level determined). See USPN 5,005,200 at Abstract. FIG. 10, steps 306, 308, 314, 328, 320, 324 relate to a plurality of nested routines required to confirm digital signatures. Checking the nested certificates for authorization is reads on claim language 'determining whether said action is authorized based on an association between permissions and a plurality of routines in a calling hierarchy associated with said principal.'
Fischer discloses wherein each routine of said plurality of routines is associated with a class.
Fischer notes an object oriented approach throughout the '717 Specification. See FIG. 3C and related text at 7: 29-8: 44, "type of object," "object programs," "data associated with this instance of the object (an instance of a class is a class object)." As an example, Fischer discloses (8: 7-11), "The object program might store...and send...(plurality of routines associated with object, where an object is an instance of a class)..."
Fischer discloses wherein said association between permissions and said plurality of routines is based on a second association between classes and protection domains.
Fischer discloses an object oriented format. An instance of an object (i.e., a program object) is derived from class template. "In one contemplated embodiment of the present invention, programs may be part of data objects, which are written in a high-level control language and are executed by a standardized interpreter program which executes this high-level language. In this case, part of the interpreter's task is to verify that the functions encountered in the high level logic are, in fact, permissible (i.e. verify associated permissions). If such tasks are not permissible, the interpreter then suppresses the execution of the program not authorized to perform such tasks." Fischer at 3:11-20.
A protection domain is represented by the PAI associated with a calling program. The PAI associates permission / authorities granted to the calling program. A calling program may have a plurality of routines, as discussed above. The class, from which the program object is derived,
has an associated PAI. 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." "In accordance with the present invention, a PAI is associated
with programs (program objects instantiated from class objects) to be executed. FIGS. 3A
through 3D depict four exemplary approaches for associating program authorization information
with a program ...."Fischer at 7:14-18, 7:49-8:2.
As previously discussed, with properly granted permissions of a calling program, subsequent program objects are placed onto the top of the call stack / execution stack and the most recently added program object may be subject to the combined constraints (authorizations) of previously added program objects, "...a program's PAI could be combined with the PAI of the program which invokes it..." (based on a second association between classes and protection domains, where the 'second association' refers to programs objects derived from classes and their associated PAIs defining authorizations, that were previously placed on the call stack) Fischer at 17:47-62.
Per claim 6, Fischer discloses a method for providing security by way of "program authorization information," or "PAI," to limit a principal's access authority to other code and resources. Fischer at 1:20-25; 2: 49-55.
Fischer discloses detecting when a request for an action is made by a principal. See
limitation addressed in rejection of claim 1 above.
in response to detecting the request, determining whether said action is authorized based on permissions associated with a plurality of routines in a calling hierarchy associated with said principal, wherein a first routine in said calling hierarchy is privileged.
Access to a calling hierarchy is disclosed, as explained above with respect to claim 1.
The limitation of "wherein a first routine in said calling hierarchy is privileged" is a variation
of the claim 1 limitation.
The Gong '476 specification describes a "privileged routine" ('476, 3: 33-37) as "allowed to perform certain actions even if the routine that called the privileged routine does not have permission to perform those same actions."
As noted above, reexamination takes a broad interpretation of claim language. The term 'routine' fairly includes within its scope such terms as function, operation, program, or method.
Fischer discloses aggregated PAI authority permissions on the call stack. The aggregated PAI may be effectively overridden by permissions granted by a "trusted authority." Fischer discloses (16: 13-65) that a program may have been signed with a public key or digital certificate, by the
manufacturer, that grants a level of authority (allowed to perform certain actions) to execute the
program (routine). "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 discloses (17: 67-18: 10), "...for called programs which carefully verify their own actions, it could be possible to allow the called program greater inherent authority (allow called program/routine to perform certain actions even if the program/routine that called the privileged routine does not have permission to perform those same actions) than the program which calls it...the possibilities for such combination must be carefully considered, not only by the designers of the underlying control system, but also by those who assign authority..." See FIG. 10, steps 306, 308, 320.
In this interpretation, a privileged called routine reads on a routine that is given greater inherent authority. The privileged called routine is referred to as a 'first routine', when the PCB representing a subsequent routine (a 'second routine') is placed on the call stack.
Fischer discloses wherein the step of determining whether said action is authorized further includes determining whether a permission required to perform said action is encompassed by at least one permission associated with each routine in said calling hierarchy between and including said first routine and a second routine in said calling hierarchy, wherein said
second routine is invoked after said first routine, wherein said second routine is a routine
for performing said requested action.
Fischer discloses (10: 24-36) "an originating program" that "calls a program" having a program control block, or PCB. "Each new PCB will include a field... that points to the 'previous' of calling program control block." Then, "[w]hen 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." The call stack data structure grows from the bottom upwards. An 'originating program' places a PCB on the call stack and an additional PCB for each subsequent program added to the call stack. The PCB at the top of the call stack represents the "second routine" and the lower PCB on the call stack represents the "first routine", arranged as a calling hierarchy. Execution begins at the top of the stack. The "first routine" is "invoked" and an associated PCB is placed on the call stack. A call to a subsequent program/routine, upon authorization, will invoke a second routine, i.e., place PCB of second routine on call stack. See Fischer, FIG. 11, #354 & #358, second program completes it actions and PCB is removed from top of stack, effectively enabling thread of execution to execute next lower program (first routine) related to next lower PCB on stack. As discussed above (17: 47-61) permissions may be encompassed by permissions associated with each routine in said calling hierarchy (i.e. PAI permissions / constraints may be combined / aggregated).
Also note, "The present invention, while it primarily focuses on defining functions which restrict
the ability of a program to access resources normally allowed to users, could also, in an
appropriate environment, be used to extend the capabilities beyond those normally allowed
to a user. Thus, for example, programs whose PAI is signed by an authority recognized by
the supervisor, could be allowed to perform extended functions." Fischer at 12:58-65.
Per claim 7, Fischer wherein the step of determining whether said permission required to perform said action is encompassed by at least one permission associated with each routine in said calling hierarchy between and including said first routine and said second routine further includes the steps of: determining whether said permission required is encompassed by at least one permission associated with said second routine.
Fischer discloses "an originating program" (a 'first routine' as it is placed in a lower position on the call stack) that "calls a program" (calling a second routine). Following a check of authorizations (if action to invoke second routine is authorized), the called routine is invoked, and the associated PCB is placed at top of the stack, resulting in a calling hierarchy represented by PCBs (first routine, second routine) on the call stack. As noted above (17: 40-18: 10), the authorizing information (constraints/permissions) found in the PAIs (associated with the PCBs and programs) is combined/merged as the stack grows. Due to the aggregated constraints (permissions), the 'routine' at the top of the call stack may encompass at least one permission associated with routines lower on the stack. See FIG. 10. (15: 63-67), A calling program calls program X for execution. The associated program control block (associated with the program X)
will not be added to the top of the execution stack until it is determined that program X is
permitted to be invoked and verification is successful completed. As an example, for a call to
Program X (first routine calling second routine), steps from #306 to #326 determine whether
permission required is encompassed by at least one permission associated with said calling
routine (calling routine/ first routine determines whether it is permitted to invoke called routine /
second routine).
See 17: 52-54, "...a calling program may not be permitted to exceed its assigned bounds by merely calling another program."
Alternately, consider Fischer teachings (16: 26-44) of determining the level of authority via digital certificates and a public key. USPN 5,005,200 (incorporated by reference) teaches a hierarchy of certificates. Fischer ('200, 30: 9-12), "The signatures and certificates are then checked to ensure that they in fact are authorized as described above in conjunction with FIG. 7."
See FIG. 7 and related text at '200, 21: 45-21: 13. Fischer discloses ('200, 22: 17-19), "All certificates must be accompanied by signatures which are themselves authorized by antecedent certificates." '200, 22: 50-55, "...a check is made to determine that antecedent certificates grant sufficient authority to the subcertificate signers to permit them to validly sign the certificate...the trust value in the certificate must be consistent with the antecedent... (determining whether said permission required is encompassed by at least one permission associated with said second routine)."
Fischer discloses in response to determining said permission required is encompassed by at
least one permission associated with said second routine, then performing the steps of:
E) selecting a next routine from said plurality of routines in said calling hierarchy;
F) if said permission required is not encompassed by at least one permission associated with said next routine, then transmitting a message, indicating that said permission required is not authorized;
G) repeating steps A and B until: said permission required is not authorized by at least one permission associated with said next routine, there are no more routines to select from said plurality of routines in said calling hierarchy, or determining that said next routine is said first routine.
Fischer '717 discloses (FIG. 10; 16: 55 - 18: 41) the sequence of operations of a supervisor program (executing supervisor routine by principal) for controlling the processing of a program being executed in accordance with its program authorization information. See Fischer '717, 16: 26-37 referencing USPN 5,005,200, describing the 'routines'/ verification operations iteratively called in a hierarchy. Fischer '717, 16: 40-44, "If the manufacturer's pedigree is not acceptable (permission is not encompassed / authorized), the routine branches...the execution of the program is suppressed..." Fischer '717, 17: 23-28, "In the process of suppressing the execution of the program, an error code or message will be returned to the calling program... (transmitting a message, indicating that said permission required is not authorized)."
The term "routine" is not narrowly defined by the '476 specification and broadly reads on a program, routine, operation, procedure, function, etc., such as calling a program to invoke or
iterating through certificates and signatures when analyzing a hierarchy of certificates as
described by Fischer '200.
As an example, see USPN 5,005,200 to Fischer (incorporated by reference) FIG. 7. See '200, 16: 59-63, "...recipient analyzes the certificates associated with the signature to determine that the proper authority has been conveyed to each certificate through its signatures and the antecedent certificate(s) of these authorizing signatures." '200, 22: 24-29, "The recipient examines every signature supplied and verifies that each accurately signs its purported object...using the procedure detailed in FIG. 3. The recipient ensures that each signature includes a corresponding validated certificate (where the recipient is the calling program that uses various routines to verify permissions)." Fischer '200, 22: 46-56, "...a check is made to ensure that all certificates except the meta-certificate have at least one signature...a check is made to ensure that all necessary cosignatures for all presented objects are present...a check is made to determine that antecedent certificates grant sufficient authority to the subcertificate signers to permit them to validly sign the certificate...the trust value in the certificate must be consistent with the antecedent..." The certificates are nested, and a first routine checking a first certificate for permissions, is followed by a next routine checking a second certificate (a subcertificate) for permissions in the hierarchy of certificates. Fischer '200, 22: 19-21, The chain of antecedent certificates is traced back recursively to the meta-certificate (there are no more routines to select from said plurality of routines in said calling hierarchy).
Per claim 10, Fischer discloses a computer-readable medium version of the limitations addressed
in claim 1 above. See 'Fischer 4: 63; '717 FIG. 3 and 7: 14-35,"...FIG. 3A ...exemplifies how
program authorization information is stored...in association with a program...identifies the
location on disk 98 of the associated program...an indicator 84, 90,...96...which identifies the
location of its associated program authorization information, e.g., PAI 1....stored in a separate
memory device 100...stored in the same memory media as its associated program (computer
readable medium)..."
Claims 11-16 are computer readable medium versions of claims 2-7 respectively. See limitations addressed in claims 2-7 and 10 above. Per claim 15, see "sequence of instructions" as shown in Fischer '717, FIGs. 10 & 11.
Claims 19-21 are system versions of claims 1, 3, and 4 respectively. See limitations addressed above. Fischer '717 teaches (Abstract; 4: 24-61) a system.
Claims 1-7,10-16,19-21 are rejected under 35 U.S.C. 103(a) as being obvious over USPN 5,958,050 to Griffin in combination with Chan.
Regarding claims 8-9 and 17-18, there are no obvious teachings in Griffin or Chan suggesting setting a flag associated with said first routine to indicate that said first routine is privileged; and the step of determining that said next routine is said first routine includes determining that a flag associated with said next routine indicates said next routine is privileged.
Per claim 1, Griffin discloses (1: 22-25) a method for providing security, i.e., "for management of trust relationships among code segments to be executed inside a trust boundary."
Griffin discloses (9: 56-64) detecting when a request for an action is made by a principal,
e.g., checking the relevant security provisions when it receives a request for "execution access for the class." "If it is determined that clearance to trust is required to grant a particular access, a path of trust must be found before the access will be granted by the trust manager. Clearance to trust might be required, for example, where a policy claim states that a particular class must be checked prior to being executed and the access requested in execution access for the class. This requirement is set by a MustCheckClaim policy claim." Griffin infers the 'principal' by ('050, 5: 22-24) disclosing a client computer 10...under the direction of...a program it is executing (execution process / thread- maps to claim term 'principal'). Griffin suggests ('050, 7: 44) the 'principal' may be executing a Web browser 16. See '050, 6: 33-51 & FIG. 3.
Griffin discloses in response to detecting the request, determining whether said action is authorized based on permissions associated with a plurality 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.
"The trust manager system also includes a code examiner adapted to analyze a portion of code to determine potential resource use of the portion of code (detecting the request) and a trust
evaluator adapted to evaluate certificate requirements of the portion of code based on policy
rules extracted from the policy file and the potential resource use specified by the code examiner
(determining whether said action is authorized based on permissions associated with said
principal). The trust evaluator also determines, from certificates from the certificate repository
and a code identifier identifying the portion of code, whether execution of the portion of code is
allowed by the policy rules given the potential resource use, the code supplier and applicable
certificates." Griffin, 3:33-57. For example, "[i]n one embodiment of a trust manager according
to the present invention, the trust manager examines each new class before it is allowed to load
(association between protection domains and permissions), execute or otherwise gain control of
resources by examining a set of claims (permissions) in a policy file and a certificate repository
(associated protection domain)." Griffin, 3:34-38. "A certificate contains one or more claims,
where a claim is a data structure defining a security policy of assertion about a class...
(permissions)" Griffin, 3: 42-45. In response to detecting the request, determining whether said
action is authorized by performed by a 'code examiner' and a 'trust evaluator.' Griffin, 3: 47-49.
"When a new class is introduced to local computer 100, modifications to class loader 124 cause a
trust manager 122 to be called before a new class is loaded. The code of the class is also
provided to a code analyzer 120 (code examiner/ detecting the request) which determines what
classes are called and what possible computer resources might be used by the code. With this
information, the trust manager reads certificates...(permissions associated with a plurality of
routines / reads and proves the hierarchy of certificates / permissions recursively back to a
'policy claim', through plurality of routines / determines whether said action is authorized)."
Griffin, 6: 52-57. The nested hierarchy of certificates required to be read and proven are reads
on the "plurality of routines."
"The operation of the system shown in FIG. 3 will now be described with reference to the flowcharts of FIGS. 4 and 5. Once a class is obtained by local computer 100, usually in response to navigation to a site which sends out Java applets, the class loader attempts to load the class. Because of the hooks placed in the standard class loader 124 (trust management modifications to classloader.c in the standard Java runtime), the class loader 124 does not pass the class on to applet runtime executive 126 unless it receives an "OK-to-load" signal from trust manager 122. Code analyzer 120 determines a unique identifier for the class (S 1), as well as a superclass reference, a list of subclasses for the class, methods of the class and a hash code of the class. Once code analyzer 120 determines this information, it passes the information to trust manager 122." Griffin, 7:10-25.
See Griffin, FIGs. 4 & 5. "If, at step S6, the trust manager determines that a subclass or method needs to be checked, that is done (S7) by the process described in FIG. 5 as in step S3. If the trust manager finds that claim to load a class with the checked subclass or method (S8) or the trust manager determined in step S6 that checking was not required, the trust manager instructs the class loader (via an OK-to-load signal, or otherwise) to load the class (S9). If, at step S4 or step S8 the trust manager cannot prove the required claim, the trust manager instructs the class loader not to load the class (S 10). At the conclusion of the process, the trust manager instructs the class
loader to either load or not load the class. It should be understood that the trust manager's output
is not limited to use in making a load/no load decision, but to the more general question of trust
or no trust. For example, the trust manager's determination could be used to decide whether to
execute code or not (in most cases, controlling code loading and code execution can achieve the
same security goals), whether to forward a message or not, or to perform a security function or
not." Griffin, 7:48-67.
This claim element would further have been obvious at the time of the invention to one of ordinary skill in the art from the teachings of Griffin, in combination with Chan. Chan notes that programs like web browsers typically define security managers. Chan discloses details of the JAVA class libraries and specifically notes "[a] security manager enforces security policies related to what a program is allowed to do." Chan, 1188. Chan deploys its security management system by, in part, referencing the source of the code currently being executed on the stack. In further detail: "A security manager enforces security policies related to what a program is allowed to do .... [Amplications like Web browsers typically define a security manager and use System.setSecurityManager to install it..." Chan, 1188. For example, Chan discloses certain "Execution Stack Information," whereby "[t]he execution stack (call stack) is a record of the method calls that were made from the main program (principal thread / process calls made to first routine, second routine, etc.) to the current method." Chan, 1189. This execution stack "indicates all the methods that are in progress and pending termination of the current method call." Id. More specifically, consider an exemplary embodiment disclosed by Chan: "For example, if mainQ calls foo(), which in turn calls bar(), the execution stack when executing
inside bar() would be bar() -> foo() -> main(). For some methods to perform some of the
permission checking (routines), they may need to inspect the execution stack to find out
information about the current execution context (first association). The SecurityManager class
provides protected methods that can be used by subclasses of the SecurityManager for this
purpose." Chan, 1189. Thus it is clear that Chan, in response to detecting a request from a
method currently on the execution stack, will determine whether the requested action is
authorized based on the permissions associated with the cascading hierarchy of calls.
Therefore it would have been obvious, to one of ordinary skill in the art, at the time of the invention to modify Griffin's disclosure of trusted execution of a web browser, with the teachings of Chan that provide more text book detail regarding the routines of a security manager as defined for a web browser.
Per claim 2, Griffin discloses detecting when a request for an action is made by a thread; the step of determining whether said action is authorized includes determining whether said action is authorized based on an association between permissions and a plurality of routines in a calling hierarchy associated with said thread.
"The preferred embodiment for use with Java applets includes the class loader and runtime executive from the Java runtime system, modified according to the present invention."
For example, "[i]n one embodiment of a trust manager according to the present invention, the
trust manager examines (trust manager process execution thread examines) each new class
before it is allowed to load (load into calling hierarchy), execute or otherwise gain control of
resources by examining a set of claims in a policy file and a certificate repository (examine each
class's association between permissions and plurality of routines in calling hierarchy)." Griffin,
3: 34-38. "If it is determined that clearance to trust is required to grant a particular access, a
path of trust must be found before the access will be granted by the trust manager. Clearance to
trust
might be required, for example, where a policy claim states that a particular class must be
checked prior to being executed and the access requested in execution access for the class.
This requirement is set by a MustCheckClaim policy claim." Griffin, 9:56-63. "If, at step S6, the
trust manager determines that a subclass or method needs to be checked, that is done (S7) by the
process (process execution thread) described in FIG. 5 as in step S3... the trust manager's
determination could be used to decide whether to execute code or not (in most cases, controlling
code loading and code execution can achieve the same security goals)...." Griffin, 7:48-67.
This claim element would further have been obvious at the time of the invention to one of ordinary skill in the art from the teachings of Griffin in combination with Chan. Chan discloses that "[a] security manager enforces security policies related to what a program is allowed to do." Chan, 1188. "[Amplications like Web browsers typically define a security manager ..." Chan, 1188. For example, Chan discloses certain "Execution Stack Information," whereby "[t]he execution stack is a record of the method calls that were made from the main program to the
current method." Chan, 1189. This execution stack "indicates all the methods that are in
progress and pending termination of the current method call." Id.
claim 3, Chan discloses (1189) a calling hierarchy that includes a first routine, as
described in the hierarchy of calls described with reference to the execution stack.
Griffin discloses the step of determining whether said action is authorized further includes determining whether a permission required to perform said action is encompassed by at least one permission associated with said first routine.
"If it is determined that clearance to trust is required (whether said action is authorized) to grant a particular access, a path of trust must be found (determining whether a permission required to perform said action is encompassed) before the access will be granted by the trust manager." Griffin, 9:56-63. "...Proving is done by finding a chain of claims from a claim about the class being loaded (check permissions associated with said first routine, where 'first routine' is associated with routine loaded on execution stack) to a claim setting out a policy statement. A certificate contains one or more claims, where a claim is a data structure defining a security policy of assertion about a class, package of classes, or an entity to be trusted or not
trusted The trust evaluator also determines, from certificates from the certificate repository
and a code identifier identifying the portion of code, whether execution of the
portion of code is allowed (determining whether said action is authorized) by the policy rules
given the potential resource use, the code supplier and applicable certificates." Griffin, 3:33-57.
Per claim 4, Griffin discloses a method wherein the step of determining whether said action is
authorized further includes determining whether a permission required to perform said
action is encompassed by at least one permission associated with each routine in said
calling hierarchy.
For example, "[i]n one embodiment of a trust manager according to the present invention, the trust manager examines each new class (determine authorization by examining each new class for permissions associated) before it is allowed to load (before adding routine to call stack / calling hierarchy), execute or otherwise gain control of resources by examining a set of claims in a policy file and a certificate repository." Griffin, 3:34-38. "The operation of the system shown in FIG. 3 will now be described with reference to the flowcharts of FIGS. 4 and 5. Once a class is obtained by local computer 100, usually in response to navigation to a site which sends out Java applets, the class loader attempts to load the class. Because of the hooks placed in the standard class loader 124 (trust management modifications to classloader.c in the standard Java runtime), the class loader 124 does not pass the class on to applet runtime executive 126 unless it receives an "OK-to-load" signal from trust manager 122. Code analyzer 120 determines a unique identifier for the class (S 1), as well as a superclass reference, a list of subclasses for the class, methods of the class and a hash code of the class. Once code analyzer 120 determines this information, it passes the information to trust manager 122." Griffin, 7:10-25.
"If it is determined that clearance to trust is required to grant a particular access, a path of trust must be found before the access will be granted by the trust manager. Clearance to trust might be required, for example, where a policy claim states that a particular class must be
checked prior to being executed and the access requested in execution access for the class.
This requirement is set by a MustCheckClaim policy claim." Griffin, 9:56-63.
Per claim 5, Griffin discloses a method for providing security,
Griffin discloses detecting when a request for an action is made by a principal. Griffin does this by, e.g., checking the relevant security provisions when it (when the executing process / principal makes a request) receives a request for "execution access for the class." Griffin, 9:61-62. "If it is determined that clearance to trust is required to grant a particular access, a path of trust must be found before the access will be granted by the trust manager. Clearance to trust (by executing process / principal) might be required, for example, where a policy claim states that a particular class must be checked prior to being executed and the access requested in execution access for the class. This requirement is set by a MustCheckClaim policy claim." Griffin, 9:56-64. "... while the trust manager described above uses a trust decision to decide whether or not to load a class, in a variant of that trust manager, all classes might be loaded and the trust decision is used to decide whether or not to execute the code..." Griffin, 10:49-56. "Certificates are signed so that they are difficult to falsify. The trust manager system also includes a code
examiner adapted to analyze a portion of code to determine potential resource use (detecting
when a request for an action is made by a principal) of the portion of code..." Griffin, 3:33-57.
Griffin discloses determining whether said action is authorized based on an association between permissions and a plurality of routines in a calling hierarchy associated with said principal.
"The operation of the system shown in FIG. 3 will now be described with reference to the flowcharts of FIGS. 4 and 5. Once a class is obtained by local computer 100 (by executing process on computer, i.e., the principal), usually in response to navigation to a site which sends out Java applets, the class loader attempts to load the class. Because of the hooks placed in the standard class loader 124 (trust management modifications to classloader.c in the standard Java runtime), the class loader 124 does not pass the class on to applet runtime executive 126 unless it receives an "OK-to-load" signal from trust manager 122 (if action is authorized). Code analyzer 120 determines a unique identifier for the class (S 1), as well as a superclass reference, a list of subclasses for the class, methods of the class and a hash code of the class. Once code analyzer 120 determines this information, it passes the information to trust manager 122." Griffin, 7:10-25. See Griffin FIGs 4 & 5. "... the trust manager instructs the class loader to either load (load onto calling hierarchy / call stack) or not load the class..." Griffin, 7:48-67. "In one embodiment of a trust manager according to the present invention, the trust manager examines each new class before it is allowed to load, execute or otherwise gain control of resources by examining a set of claims in a policy file and a certificate repository. The trust
manager proves a claim before allowing a class to be loaded if a policy statement requires
proof. Proving is done by finding a chain of claims from a claim about the class being
loaded to a claim setting out a policy statement (association between permissions and a plurality
of routines in a calling hierarchy associated with said principal). A certificate contains one or
more claims, where a claim is a data structure defining a security policy of assertion about a
class, package of classes, or an entity to be trusted or not trusted. Certificates are signed so that
they are difficult to falsify. The trust manager system also includes a code examiner adapted to
analyze a portion of code to determine potential resource use of the portion of code and a trust
evaluator adapted to evaluate certificate requirements of the portion of code based on policy
rules extracted from the policy file and the potential resource use specified by the code examiner.
The trust evaluator also determines, from certificates from the certificate repository and a code
identifier identifying the portion of code, whether execution of the portion of code is allowed by
the policy rules given the potential resource use, the code supplier and applicable certificates."
Griffin, 3:33-57.
Chan provides supporting details regarding security manager functionality typically found in Web browsers (where web browsers were disclosed by Griffin). Chan discloses that "[a] security manager enforces security policies related to what a program is allowed to do." Chan, 1188. Chan deploys its security management system by, in part referencing the source of the code currently being executed on the stack. "A security manager enforces security policies (permissions) related to what a program is allowed to do .... [Amplications like Web browsers typically define a security manager and use System.setSecurityManager to install it..." Chan,
1188. Chan discloses certain "Execution Stack Information," (calling hierarchy) whereby "[t]he
execution stack is a record of the method calls that were made from the main program to the
current method." Chan, 1189. This execution stack "indicates all the methods that are in
progress and pending termination of the current method call." Id. For some methods to perform
some of the permission checking, they may need to inspect the execution stack to find out
information about the current execution context (calling hierarchy associated with said
principal). The SecurityManager class provides protected methods that can
be used by subclasses of the SecurityManager for this purpose." Chan, 1189.
Griffin discloses each routine of said plurality of routines is associated with a class. Griffin discloses (6: 48-51) class loaders from a Java runtime system. Such a class loader evaluates routines associated with a class.
Griffin discloses said association between permissions and said plurality of routines is based on a second association between classes and protection domains.
"If it is determined that clearance to trust is required to grant a particular access (association between permissions and plurality of routines), a path of trust must be found before the access will be granted by the trust manager. Clearance to trust might be required, for example, where a policy claim states that a particular class must be checked prior (second association between classes to be loaded and trust / protection domains) to being executed and the access requested in execution access for the class. This requirement is set by a MustCheckClaim policy claim." Griffin, 9:56-63.
Per claim 6, Griffin discloses (1: 22-25) a method for providing security. "The present invention relates to the field of trust management in a distributed control environment. More specifically, one embodiment of the invention provides for management of trust relationships among code segments to be executed inside a trust boundary." See Griffin method claims 1-12, 11:63-14: 13.
Griffin discloses detecting when a request for an action is made by a principal. See
limitations addressed in claim 1 above.
Griffin discloses in response to detecting the request, determining whether said action is authorized based on permissions associated with a plurality of routines in a calling hierarchy associated with said principal, wherein a first routine in said calling hierarchy is privileged.
Claim 6 differs from claim 1 with the recitation, "wherein a first routine in said calling hierarchy is privileged."
Gong '476 discusses the term 'privileged' at 3: 33-37; 6: 35-39; 13: 22-35: "...certain routines may be 'privileged'. A privileged routine is allowed to perform certain actions even if the
routine that called the privileged routine does not have permission to perform those same
actions." "When determining whether a thread is able to perform an action, only the permissions
associated with the privileged routine and the routines above the privileged routine in the calling
hierarchy of the thread are inspected." "...a method may cause itself to be privileged (i.e. enable
the privilege mechanism) by invoking a method of a privilege object called, for example,
beginPrivilege."
Broadly Gong '476 discloses (3: 3-11) the term 'routine' includes within its scope such terms as functions or methods. Actions are authorized based on permissions associated with calling routines (authorized called routines invoked and placed on the call stack). "A calling hierarchy indicates the routines (e.g. functions, methods) that have been invoked (and placed on the call stack) by or on behalf of a principal (e.g. thread, process) but have not been exited."
Broadly Griffin discloses (4: 49-57) that "[t]he process of proving a claim is one of verifying the claimant, a level of trust in the claimant and the authorization of that claimant (prove by verifying claim is privileged), typically using other claims. This leads to a chain of claims ending with a known trust claim or claimant. A claim makes an assertion. An assertion could be that a particular element can be trusted, that a particular class should not be trusted, that a particular class can be trusted, etc."
Griffin in view of Chan discloses the step of determining whether said action is authorized
further includes determining whether a permission required to perform said action is
encompassed by at least one permission associated with each routine in said calling
hierarchy between and including said first routine and a second routine in said calling
hierarchy, wherein said second routine is invoked after said first routine, wherein said
second routine is a routine for performing said requested action.
A calling hierarchy represents the sequence of calls to routines (calls to programs / procedures / functions/ methods / operations, etc), where a requested action (by calling routine) to load the routine (action requesting to invoke/load called routine) on the call stack (an action to invoke a routine) is made by the principal thread or process of execution. If each routine requested to be loaded is authorized to be loaded, it is sequentially placed on the call stack / execution stack (invoked). The routine associated with the top of the call stack represents the 'second routine.' The routine associated with the position just prior to the second routine represents the 'first routine.'
Chan discloses that "[a] security manager enforces security policies related to what a program is allowed to do." Chan, 1188. Chan deploys its security management system by, in part, referencing the source of the code currently being executed on the stack. In further detail: "A security manager enforces security policies related to what a program is allowed to do .... [Amplications like Web browsers typically define a security manager and use System.setSecurityManagerto install it..." Chan, 1188. Chan discloses certain "Execution
Stack Information," whereby "[t]he execution stack is a record of the method calls (calls to
routines) that were made from the main program (from the principal) to the current method."
Chan, 1189. This execution stack "indicates all the methods that are in progress (each routine in
a calling hierarchy) and pending termination of the current method call." Id. (where current
method call references the top of the stack or otherwise the 'second routine; first routine is
referenced after the second routine exits execution).'
"... For some methods to perform some of the permission checking, they may need to inspect the execution stack to find out information about the current execution context. The SecurityManager class provides protected methods that can be used by subclasses of the SecurityManager for this purpose." Chan, 1189. Thus it is clear that Chan, in response to detecting a request from a method currently on the execution stack, will determine whether the requested action is authorized based on the permissions associated with the cascading hierarchy of calls (permissions associated with each routine in said calling hierarchy / permissions of routines prior to the 'second routine', i.e. permissions of the first routine).
Per claim 7, Griffin in view of Chan discloses the step of determining whether said permission required to perform said action is encompassed by at least one permission associated with each routine in said calling hierarchy between and including said first routine and said second routine further includes the steps of: determining whether said permission required is encompassed by at least one permission associated with said second
routine; and in response to determining said permission required is encompassed by at
least one permission associated with said second routine, then performing the steps of:
A) selecting a next routine from said plurality of routines in said calling hierarchy, B) if said permission required is not encompassed by at least one permission associated with said next routine, then transmitting a message indicating that said permission required is not authorized, and C) repeating steps A and B until: said permission required is not authorized by at least one permission associated with said next routine, there are no more routines to select from said plurality of routines in said calling hierarchy, or determining that said next routine is said first routine.
Griffin discloses (9: 12-16) that "[t]he trust manager will keep searching for a path through the web of claims, using hints as needed, moving up and down along a path (repeat with next routine) as dead ends are encountered. Eventually, the trust manager may exhaust all possible hints and have searched all available claims. "If it is determined that clearance to trust is required to grant a particular access, a path of trust must be found before the access will be granted by the trust manager.... " Griffin, 9:56-64. Griffin discloses (13: 17-18),"...when a path of trust cannot be found after a finite search, denying the object the access."
Chan discloses that "[a] security manager enforces security policies related to what a program is allowed to do." Chan, 1188. Chan deploys its security management system by, in part, referencing the source of the code currently being executed on the stack. In further detail: "A
security manager enforces security policies related to what a program is allowed to do ....
[Amplications like Web browsers typically define a security manager... " Chan, 1188.
Chan discloses certain "Execution Stack Information," whereby "[t]he execution stack is a record of the method calls that were made from the main program to the current method." Chan, 1189. This execution stack "indicates all the methods that are in progress and pending termination of the current method call." Id.
Chan discloses (Chan, 1189) a recursive inspection of the call stack, until there are no more routines to select from: "For example, if main() calls foo(), which in turn calls bar(), the execution stack when executing inside bar() would be bar() -> foo() -> main(). For some methods to perform some of the permission checking, they may need to inspect the execution stack to find out information about the current execution context..."
Griffin discloses "denying the object the access" when a path of trust cannot be found. Griffin fails to disclose transmitting a message indicating that said required permission is not authorized. It would be obvious to transmit a message indicating that said required 'permission' is not authorized. See Griffin, FIG. 5, last step. To transmit such a message would be within the skill level of one of ordinary skill in the art and would provide useful information to a program operator."
Chan shows that methods of the Security Manager can throw an exception. It would be obvious
to one of ordinary skill in the art to create within the exception code block a message to be
transmitted indicating that said permission required is not authorized. Such a modification
would be well within the skills of one of ordinary skill in the art.
Claim 10 is a computer readable medium version of limitations addressed in claim 1 above. Griffin discloses (FIG. 2) a computer, including a CPU and hard drive and (FIG. 3) the trust manager software components stored on a client computer being protected. See Griffin (7: 15-17) "trust management modifications to classloader.c in the standard Java runtime" in reference to code modifications stored on a computer readable medium of a trusted delegation system.
See limitations of claims 11-16 addressed above in claims 2-7 respectively.
Claim 19 is a system version of limitations addressed in claim 1 above. Griffin discloses (3: 47; 6: 33-34; 14: 14-60) a system that performs the methods steps previously discussed. "FIG. 3 is a detailed block diagram of a trust management system which can provide the access control for a local computer 100."
Claims 20 and 21 are system versions of limitations addressed in claims 3 and 4 above.
Additional teachings by Organick are cumulative to the art. Proposed rejections in view of Organick are held in abeyance.
In summary, claims 1-7, 10-16, and 19-21 are rejected. Claims 8- 9 and 17-18 are confirmed, as there are no prior art disclosures of the "setting a flag" limitation.
Conclusion
In order to ensure full consideration of any amendments, affidavits or declarations, or other documents as evidence of patentability, such documents must be submitted in response to this Office action. Submissions after the next Office action, which is intended to be a final action, will be governed by the requirements of 37 CFR 1.116, after final rejection and 37 CFR 41.33 after appeal, which will be strictly enforced.
Any paper filed with the USPTO, i.e., any submission made, by either the Patent Owner or the Third Party Requester must be served on every other party in the reexamination proceeding, including any other third party requester that is part of the proceeding due to merger of the reexamination proceedings. As proof of service, the party submitting the paper to the Office must
attach a Certificate of Service to the paper, which sets forth the name and address of the party served and the method of service. Papers filed without the required Certificate of Service may be denied consideration. See 37 CFR 1.550(f)
