(12) United States Patent
`Balassanian
`
`111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US006324685Bl
`US 6,324,685 Bl
`*Nov. 27, 2001
`
`(10) Patent No.:
`(45) Date of Patent:
`
`(54) APPLET SERVER THAT PROVIDES
`APPLETS IN VARIOUS FORMS
`
`(75)
`
`Inventor: Edward Balassanian, Kirkland, WA
`(US)
`
`(73) Assignee: BeComm Corporation, Redmond, WA
`(US)
`
`( *) Notice:
`
`This patent i·ssued on a continued pros(cid:173)
`ecution application filed under 37 CPR
`!.53( d), and is subject to the twenty year
`patent term provisions of 35 U.S.C.
`154(aX2).
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(21) Appl. No.: 09/040,972
`
`Mar. 18, 1998
`
`(22) Filed:
`Int. CJ.7
`(51)
`... ...................... ... ... ... ... ........ ... ... ... .. Gtl6F 9/45
`(52) U.S. CJ ....................................................... 717/5; 717/1
`(58) Field of Search ..................................... 395/705, 701,
`395/200.33, 200.32, 188.Ql; 717/5, 1; 709/203,
`202; 713/202
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,805,829 • 9/1998 Cohen ei a!. ................... 395/200.32
`5,828,840 • 10/1998 Cowan et al. .................. 395/200.33
`5,848,274 • 12/1998 Hamby et at. ....................... 395/iOS
`5,872,915 • 2/ 1999 Dykes et at. .................... 395/ 188.01
`5,884,078 • 3/1999 Faustini ................................ 395/iOl
`
`OTHER PUBLICATIONS
`
`" Eliminating Unnecessary Synchronization," http://kimer(cid:173)
`a.cs.washington.edu/synch/index.html [Accessed Oct. 4,
`2000].
`
`Sirer, Emin Gtin, " Kimera Paper Trail," http://kimera.cs(cid:173)
`.washington.edu/papers/index.html [Accessed Oct. 4, 2000).
`Sirer, Emin Giin, "Java, Extensibility and Security Related
`Links," http://kimera.cs. washington .edu/related/index. html
`[Accessed Oct. 4, 2000].
`Sirer, Ernin Giin, "Java-Relevant Articles in the Press,"
`http://kimera.cs.washington.edu/press/index.html
`[Ac(cid:173)
`cessed Oct. 4, 2000].
`"Project Members" http://kimera.cs.washington.edu/mem(cid:173)
`bers.btml [Accessed Oct. 4, 2000).
`Emin Giin Sirer, et al., ·'Distributed Virtual Machines: A
`System Architecture for Network Computing," Dept. of
`Computer Science & Engineering, University of Washing(cid:173)
`ton, Seattle, Washington http://kimera.cs.washington.edu
`Feb. 26, 1998.
`
`(List continued on next page.)
`
`Primary Examiner-Mark R. Powell
`Assistant Examiner-Hoang-Vu Antony Ng-uyen-Ba
`(74) Attorney, Agent, or Firm-Perkins Coie LLP
`
`(57)
`
`ABSTRACT
`
`The present invemion is an applet server which accepts
`requests for applets from client computers. A request speci(cid:173)
`fies the format in which an applet is to be delivered to the
`requesting clie.nt computer. The applet server has a cache
`which it uses to store appleis for distribution to client
`computers. If the specified form of the requested applet is
`available in the cache, the applet server transmits the applet
`to the requesting client. If the applet is not available in the
`cache, the server will attempt to build the applet from local
`resources (program code modules and compilers) and trans(cid:173)
`former programs (verifiers and optimizers). If the applet
`server is able to build the requested applet, it will then
`transmit the applet to the requesting client computer. If the
`applet server is unable to build the requested applet, it will
`pass the request to another applet server on tbe network fo r
`fulfillment of the request.
`
`106 Claims, 3 Drawing Sheets
`
` Exhibit 1024 Page 1
`
` SYMANTEC
`
`

`
`US 6,324,685 Bl
`Page 2
`
`01HER PUBLICATIONS
`
`Emin Gun Sirer, et al., "Design and Implementation of a
`Distributed Virtual Machine for Networked Computers,"
`University of Washington, Department of Computer Science
`and Engineering, Seattle Washington, 17'h ACM Sympo(cid:173)
`sium on Operating system Principles, Dec. 1999.
`Sirer, Emin Gun, "A System Architecture for Next Genera(cid:173)
`tion Network Computing," Dept. of Computer Science &
`Engineering, University of Washington, Seattle, Washington
`http://www.dyncorp-is.com/darpa/meetings/gradmeet98/
`Whitepapers/darpa-wp.html Jun. 26, 1998.
`Sirer, Emin Gun, http://www.cs.washington.edu/homes/egs/
`[Accessed Oct. 4, 2000].
`Sirer, Emin Gun, "Kimera-A System Architecture for
`Networked Computers," http:/ /kimera.cs.washington.edu/
`[Accessed Oct. 4, 2000].
`
`Emin Gun Sirer and Brian Bershad, "Kimera Architecture,"
`http:/ /kimera.cs.washington.edu/overview.html
`[Accessed
`Oct. 4, 2000].
`Sirer, Emin Gun, "Security Flaws in Java Implementations,"
`http:/ /kimera.cs.washington.edu/fiaws/index.html
`[ Ac(cid:173)
`cessed Oct. 4, 2000].
`Sirer, Emin Gun, "Kimera Bytecode Verification," http://
`kimera.cs.washington.edu/verifier.html [Accessed Oct. 4,
`2000].
`Sirer, Emin Gun, "Kimera Test Suite," http://kimera.cs(cid:173)
`.washington.edu/testsuite.html [Accessed Oct. 4, 2000].
`Sirer, Emin, Gun, "Kimera Disassembler," http://kimera.c(cid:173)
`s.washington.edu/disassembler.html
`[Accessed Oct. 4,
`2000].
`
`* cited by examiner
`
` Exhibit 1024 Page 2
`
` SYMANTEC
`
`

`
`U.S. Patent
`
`Nov. 27, 2001
`
`Sheet 1 of 3
`
`US 6,324,685 Bl
`
`Client Computer A
`
`12
`
`Client Computer B
`
`14
`
`Untrusted
`Network
`
`16
`
`10
`
`Applet Server Computer
`
`Network Interface
`
`20
`
`Applet Server
`Manager
`
`22
`
`Local Resources
`
`1
`
`1€2
`
`I
`
`r - __(~-
`d32a
`lf I
`30a® I
`832bl
`~32c
`C!:) I
`30b ®32dl
`I
`
`Cache Component
`
`24
`
`c Applet 1 ~25a
`( Applet 2 ~25b
`c Applet 3 ~25c
`I 1\ _ Transfor,;;;;s -
`IL::3,. 36-e :
`
`241
`
`30c
`___ _J
`
`1
`
`-
`
`L::-- 28 ) - - -
`
`Fig.l
`
` Exhibit 1024 Page 3
`
` SYMANTEC
`
`

`
`U.S. Patent
`
`Nov. 27, 2001
`
`Sheet 2 of 3
`
`US 6,324,685 Bl
`
`Code-Type
`
`Verification-Level
`
`Optimization-Level
`
`Code-Type
`
`Verification-Level
`
`Optimization-Level
`
`Applet Length
`
`Applet Code
`
`(String) specifies the name of the requested
`et
`(Source/Intermediate/Binary) specifies the
`format the applet is to be delivered to the
`requesting client in. A request for binary
`would specify the CPU of the requesting
`client
`(0-100) specifies the degree of verification to
`be performed. 0 = no/minimal verification,
`100 = maximum verification (highest level of
`
`Fig. 2A
`
`(Source/Intermediate/Binary) specifies the
`format the applet is to be delivered to the
`requesting client in. A request for binary
`would specify the CPU of the requesting
`client
`(0-1 00) specifies the degree of verification to
`be performed. 0 = no/minimal verification,
`1 00 = maximum verification (highest level of
`secu
`(0-100) specifies the degree of optimization
`to be performed. 0 = no/minimal
`1 00 = maximum
`·
`'""'"'"'t"'"
`
`Fig. 2B
`
` Exhibit 1024 Page 4
`
` SYMANTEC
`
`

`
`U.S. Patent
`
`Nov. 27, 2001
`
`Sheet 3 of 3
`
`US 6,324,685 Bl
`
`Intermediate Compiler
`
`40
`
`42
`
`44
`
`I 9 T"MfO<me<s
`r --- - -- -
`
`I
`
`r
`
`46
`
`- - -
`
`48
`
`I
`ll
`.J
`
`56
`
`--
`
`50
`
`52
`
`Target Compiler
`
`Applet
`
`54
`
`Fig. 3
`
` Exhibit 1024 Page 5
`
` SYMANTEC
`
`

`
`US 6,324,685 Bl
`
`1
`APPLET SERVER THAT PROVIDES
`APPLETS IN VARIOUS FORMS
`FIELD OF THE INVENTION
`The present invention relates to computer operating sys(cid:173)
`tems and, in particular, to a server architecture providing
`application caching and security verification.
`
`10
`
`20
`
`25
`
`BACKGROUND OF THE INVENTION
`The growth of the Internet's importance to business,
`along with the increased dependence upon corporate
`networks has created a demand for more secure and efficient
`compute; systems. The traditional solution to this problem
`has been to depend upon improvements in hardware perfor(cid:173)
`mance to make up for the performance penalty that is 15
`typically incurred when a computer system is made more
`secure and stable. Increased interconnectivity has also cre(cid:173)
`ated a need for improved interoperability amongst a variety
`of computers that are now connected to one another. One
`solution to the problem of the variety of computers inter-
`connected via the Internet and corporate networks has been
`the development of portable architecture neutral program(cid:173)
`ming languages. The most widely known of these is Java,
`though, there are numerous other architecture neutral lan(cid:173)
`guages.
`Architecture neutral programming languages allow pro(cid:173)
`grams downloaded from a server computer to a client
`computer to be interpreted and executed locally. This is
`possible because the compiler generates partially compiled
`intermediate byte-code, rather than fully compiled native 30
`machine code. In order to run a program, the client machine
`uses an interpreter to execute the compiled byte-code. The
`byte-codes provide an architecture neutral object file format,
`which allows the code to be transported to multiple plat(cid:173)
`forms. This allows the program to be run on any system 35
`which implements the appropriate interpreter and run-time
`system. Collectively, the interpreter and runtime system
`implement a virtual machine. This structure results in a very
`secure language.
`The security of this system is premised on the ability of 40
`the byte-code to be verified independently by the client
`computer. Using Java or some other virtual machine imple(cid:173)
`menting technology, a client can ensure that the downloaded
`program will not crash the user's computer or perform
`operations for which it does not have permission.
`The traditional implementations of architecture neutral
`languages are not without problems. While providing tre(cid:173)
`mendous cross platform support, the current implementa(cid:173)
`tions of architecture neutral languages require that every
`client performs its own verification and interpretation of the 50
`intermediate code. The high computation and memory
`requirements of a verifier, compiler and interpreter restrict
`the applicability of these technologies to powerful client
`computers.
`Another problem with performing the verification process 55
`on the client computer is that any individual within an
`organization may disable some or all of the checks per(cid:173)
`formed on downloaded code. The current structure of these
`systems makes security management at the enterprise level
`almost impossible. Since upgrades of security checking 60
`software must be made on every client computer, the cost
`and time involved in doing such upgrades makes it likely
`that outdated or corrupt copies of the verifier or interpreter
`exist within an organization. Even when an organization is
`diligent in maintaining a client based security model, the 65
`size of the undertaking in a large organization increases the
`likelihood that there will be problems.
`
`2
`There is a need for a scalable distributed system arc hi(cid:173)
`tecture that provides a mechanism for client computers to
`request and execute applets in a safe manner without re.quir(cid:173)
`ing the client machines to have local resources to compile or
`5 verify the code. There is a further need for a system in which
`the applets may be cached in either an intermediate archi(cid:173)
`tecture neutral form or machine specific form in order to
`increase overall system performance and efficiency.
`SUMMARY OF THE INVENTION
`In accordance with one embodiment of the invention, an
`applet server architecture is taught which allows client
`computers to request and execute applets in a safe manner
`without requiring the client to have local resources to verify
`or compile the applet code. Compilation and byte-code
`verification in the present invention are server based and
`thereby provide more efficient use of resources and a flexible
`mechanism for instituting enterprise-wide security policies.
`The server architecture also provides a cache for applets,
`allowing clients to receive applet code without having to
`access nodes outside the local network. The cache also
`provides a mechanism for avoiding repeated verification and
`compilation of previously requested applet code since any
`client requesting a given applet will have the request satis(cid:173)
`fied by a single cache entry.
`Machine specific binary code is essentially interpreted
`code since the processor for a given computer can essen(cid:173)
`tially be viewed as a form of an interpreter, interpreting
`binary code into the associated electronic equivalents. The
`present invention adds a level of indirection in the form of
`an intermediate language that is processor independent. The
`intermediate language serves as the basis for security
`verification, code optimizations, or any other compile time
`modifications that might be necessary. The intermediate
`form allows a single version of the source to be stored for
`many target platforms instead of having a different binary
`for each potential target computer. Compilations to the target
`form can either be done at the time of a cache hit or they can
`be avoided all together if the target machine is able to
`directly interpret the intermediate form. If the compilation is
`done on the server, then a copy of the of the compiled code
`as well as the intermediate form can be stored in the cache.
`The performance advantage derived from caching the com(cid:173)
`piled form as well as the intermediate depends upon the
`number of clients with the same CPU.
`The novel features believed characteristic of the invention
`are set forth in the appended claims. The invention itself,
`however, as well as other features and advantages thereof
`will best be understood by reference to the detailed descrip(cid:173)
`tion which follows, when read in conjunction with the
`accompanying drawings.
`
`45
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is diagram showing the major components which
`may be used to implement an applet server in one embodi(cid:173)
`ment of the present invention;
`FIG. 2a is a table which illustrates the structure of the
`request format data type;
`FIG. 2b is a table which illustrates the structure of the
`returned code data type.
`FIG. 3 is a diagram showing the compilation and trans(cid:173)
`formation of a program module into an applet in a particular
`form.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`Referring to FIG. 1, an applet server architecture accord(cid:173)
`ing to one embodiment of the invention is based on an applet
`
` Exhibit 1024 Page 6
`
` SYMANTEC
`
`

`
`US 6,324,685 Bl
`
`10
`
`3
`server computer 10 which in turn is connected to client
`computer A12, client computer B14, an external network 16
`and an untrusted network 18. The applet server computer 10
`connects to client computers 12 and 14, an external network
`16, and an untrusted network 18 by means of a network
`interface 20. Typically this connection will involve one or
`more of the computers or networks having a connection to
`the Internet.
`The applet server computer 10 accomplishes its objectives
`by manipulating computer programs in several formats. An
`applet (e.g. applets 1-3, 25a-25c) is any form of program
`instructions, whether in binary, source or intermediate for(cid:173)
`mat. In the case of this architecture, the applet code can
`either be a self contained program, or it can be a code
`fragment associated with a larger application.
`Binary format refers to processor specific machine
`instructions suitable for running natively on a given com(cid:173)
`puting platform (also referred to as "target" because of the
`concept of "targeting" a compiler to produce binary code for
`a given processor type).
`Source refers to non-binary applet code, generally in the
`form of higher level languages (i.e. C, C++, Java, Visual
`Basic, ActiveX, Fortran, and Modula).
`Intermediate format refers to a common intermediate
`byte-code that is produced by compiling a given source code
`input. The intermediate byte-code need not necessarily be
`Java byte-code.
`Treating applets in this general sense allows client com(cid:173)
`puters 12 and 14 to request not only applications, but
`portions of applications. Client computers 12 and 14 are thus
`able to use applet server computer 10 as the equivalent of a
`loader, loading in appropriate parts of the application in the
`form of applets. In turn client computers 12 and 14 can run
`large applications without requiring that the client comput(cid:173)
`ers 12 and 14 have the resources to store the entire appli(cid:173)
`cation in memory at once.
`Having the applets delivered from applet server computer
`10 allows code in intermediate form to be verified,
`optimized, and compiled before being transmitted to client
`computers 12 and 14. This reduces the amount of work the
`client computers 12 and 14 have to do and provides a
`convenient way to impose global restrictions on code.
`In operation, client computer A 12 transmits a request to
`an applet server computer 10 requesting an applet in a
`particular form. The form may be selected from a large
`matrix of many possible forms that can be recognized by the
`system. The request specifies the format (source,
`intermediate, or binary) in which the client wishes to receive
`the applet. The request may also specify that the applet be
`verified or have some other transformation operation per(cid:173)
`formed upon it. Verification, optimization and compression
`are examples of types of transformation operations. The
`request is received by the network interface 20 of the applet
`server computer 10 which passes the request onto the applet
`server manager 22.
`After interpreting the request, the applet server manager
`22 checks to see if the requested applet is available in the
`cache 24. The cache 24 stores applets in a variety of formats
`(source, intermediate, or binary). If the requested form of the 60
`applet is available in the cache 24 ( applet 1 25a, applet 2
`25b, or applet 3 25c in this example) the applet server
`manager 22 instructs the network interface 20 to transmit the
`applet to requesting client computer A 12. If the requested
`applet is not available in the cache 24, then the applet server 65
`manager 22 will attempt to build the requested applet from
`local resources 26 and one or more transformation opera-
`
`4
`tions performed by one or more of the transformers 28.
`Local resources 26 are comprised of compilers 30a, 30b and
`30c and program code modules 32a, 32b, 32c and 32d. The
`requested applet is built by selecting one or more program
`5 code modules 32 and compiling them with one or more
`compilers 30. Transformer operations may be performed by
`the verifier 34 or the optimizer 36. After the applet server
`manager 22 builds the applet, the network interface 20
`transmits the applet to the requesting client computer A 12.
`If the request can not be satisfied by building the applet
`from local resources 26 and transformers 28, the applet
`server manager 22 will pass a request for the requested
`applet to external network 16 and/or untrusted network 18.
`The applet server manager 22 may request the applet in
`intermediate form or in executable form or it may request the
`15 local resources 26 and transformers 28 it needs to complete
`building the applet itself.
`The cache 24 is capable of responding to the following
`commands: GET, PUT, and FLUSH. GET is used to retrieve
`a given applet from the cache. PUT is used to store an applet
`20 in the cache. FLUSH is used to clear the cache of one or
`more entries. When the cache is unable to locate an item in
`response to a GET operation, it returns a cache miss. The
`program which issued the GET command is then responsible
`for locating the desired form of the applet by other means
`25 and optionally storing it in the cache when it is retrieved
`(using the PUT operation). The FLUSH command will clear
`the cache of one or more entries and any subsequent GETs
`for the FLUSHed applet code will result in a cache miss.
`This is useful if a particular applet needs to be updated from
`30 a remote server on a periodic basis. When using PUT, the
`program issuing the command specifies a time to live (TTL)
`in the cache. When the TTL expires, the cache entry is
`removed by means of a FLUSH operation.
`Local resources 26 are comprised of program modules 32
`35 (applets in source form, not the requested form) and com(cid:173)
`pilers 30. The program modules 32 are run through the
`compilers 30 in order to produce applets in the requested
`form. The applet server manager 20 may also direct the
`modules 32 to be processed by a verifier 34 or another
`40 transformer such as an optimizer 36. Program modules 32
`are program code used to build applets. Program modules 32
`may be stored in local resources 26 in source, binary, or
`intermediate formats. When an applet is built it may require
`the operation of one or more compilers 30 upon one or more
`45 program modules 32. The program modules 32 may be
`combined and recompiled with previously cached applets
`and the resulting applet may be also cached for use at a
`future time. Additionally, program modules 32, compilers 30
`and transformers 28 (including verifiers 34 and optimizers
`50 36) may be distributed across a network. The applet server
`manager 22 may pass requests for the components it needs
`to build a particular applet back to the network interface 20
`which in turn passes the request onto the rest of the network
`and may include external network 16 and untrusted network
`55 18.
`FIG. 3 provides further illustration of how an applet is
`produced from local resources and transformers. In this
`illustration the request is for an optimized and verified applet
`compiled to a machine specific form. A program module 40
`is compiled into an intermediate form program module 44
`by an intermediate compiler 42. The intermediate form
`program module 44 is then transformed by an optimizer 46
`or a verifier 48. The resulting transformed intermediate form
`program module 50 is then compiled by target compiler 52
`into machine specific code applet 54.
`There are two types of compilers used to build applets:
`intermediate compilers 42 and target compilers 52. The
`
` Exhibit 1024 Page 7
`
` SYMANTEC
`
`

`
`US 6,324,685 Bl
`
`10
`
`5
`intermediate compiler 42 compiles program modules
`(source applet code) 40 and produces a common interme(cid:173)
`diate pseudo-binary representation of the source applet code
`(intermediate form program module 44). The word pseudo is
`used because the intermediate form 44 is not processor 5
`specific but is still a binary representation of the source
`program module 40. This intermediate form can be
`re-targeted and compiled for a particular processor.
`Alternatively, the intermediate form 44 can be interpreted by
`an interpreter or virtual machine that understands the inter-
`nal binary representation of the intermediate form. A target
`compiler 52 compiles intermediate applet code 44 into an
`applet 54 in a processor specific format (binary) suitable for
`running natively on a given computing platform.
`Transformers 56 are programs that take in intermediate 15
`code and put out intermediate code. Transformers 56 are
`generally used for things like verification and optimization.
`Other transformers might included compressors that identify
`portions of code that can be replaced with smaller equiva(cid:173)
`lents. Transformers can be matched up to any other com- 20
`ponent that takes in intermediate code as an input. These
`include the cache 24 and the target compilers 52. Global
`policies for transformers 56 can be implemented which
`ensure that all applets are run through some set of trans(cid:173)
`formers before being returned to the client.
`A verifier 48 is a type of transformer that is able to analyze
`input code and determine areas that might not be safe. The
`verifier 48 can determine the level of safety. Some verifiers
`48 look for areas where unsafe or protected memory is being
`accessed, others might look for accesses to system resources 30
`such as 10 devices. Once a verifier 48 determines the portion
`of unsafe applet code several steps can be taken. The
`offending code portion can be encased with new code that
`specifically prevents this unsafe code section from being
`executed. The unsafe code can be modified to be safe. The 35
`unsafe code can be flagged in such a way that a user can be
`warned about the possible risks of executing the code
`fragment. The verifier's role can therefore be summarized as
`determining where unsafe code exists and possibly altering
`the offending code to render it harmless. Verifiers 48 can
`operate on any format of input code, whether in source,
`intermediate or binary form. However, since intermediate
`code is a common format, it is most efficient to have a single
`verifier that will operate on code in this format. This
`eliminates the need to build specific knowledge of various
`source languages into the verifier. Verifiers 48 are a form of
`a transformer. Verifiers 48 take in intermediate code and put
`out verified intermediate code. Verifiers 48 are responsible
`for identifying non-secure portions of code in the interme(cid:173)
`diate code and modifying this code to make it secure. 50
`Security problems generally include access to memory areas
`that are unsafe (such as system memory, or memory outside
`the application space of the applet).
`The choice of adding in the verification step can be left up
`to the client computer 12, the applet server computer 10 (see 55
`FIG. 1), or can be based on the network that the applet
`originated from. Server managers can institute global poli(cid:173)
`cies that affect all clients by forcing all applets to be run
`through the verifier 48. Alternatively, verification can be
`reserved for un-trusted networks (18 in FIG. 1), or it can be 60
`left up to the client to determine whether the verification
`should be performed. In the preferred embodiment, verifi(cid:173)
`cation level is determined by the applet server 10. In this
`way, a uniform security policy may be implemented from a
`single machine (i.e., the applet server 10).
`Optimizers 46 are another type of transformer program.
`Optimizers 46 analyze code, making improvements to well
`
`6
`known code fragments by substituting in optimized but
`equivalent code fragments. Optimizers 46 take in interme(cid:173)
`diate code 44 and put out transformed intermediate code 50.
`The transformed intermediate code 50 is functionally
`equivalent to the source intermediate code 44 in that they
`share the same structure.
`Referring again to FIG. 1, policies may be instituted on
`the applet server 10 that force a certain set of request
`parameters regardless of what the client asked for.
`For example, the applet server manager 22 can run the
`applet through a verifier 34 or optimizer 36 regardless of
`whether the client 12 requested this or not. Since the server
`10 might have to go to an untrusted network 18 to retrieve
`a given applet, it will then run this applet through the
`required transformers 28, particularly the verifier 34 before
`returning it to the client 12. Since clients 12 and 14 have to
`go through the applet server computer 10, this ensures that
`clients 12 and 14 do not receive applets directly from an
`untrusted network 18. In addition, since the server will be
`dealing directly with untrusted network 18, it can be set up
`to institute policies based on the network. A trusted external
`network 16 may be treated differently than an untrusted
`network 18. This will provide the ability to run a verifier 34
`only when dealing with an untrusted network 18, but not
`25 when dealing with a trusted external network 16. In one
`embodiment, all intermediate code is passed through a
`verifier 34 and the source of the code merely determines the
`level of verification applied.
`The client 12 is the target computer on which the user
`wishes to execute an applet. The client 12 requests applets
`from the server 10 in a specific form. Applets can be
`requested in various formats including source, intermediate
`and binary. In addition, an applet can be requested with
`verification and/or other compile time operations.
`Optionally, the client 12 can pass a verifier to the server to
`provide verification. If the server 10 implements its own
`security, then both the client and server verifiers will be run.
`The verifier that is passed from the client to the server is
`cached at the server for subsequent verification. The client
`40 can refer to this verifier by a server-generated handle to
`avoid having to pass the verifier each time an applet is
`requested.
`Client computers 12 and 14 requesting applet code in
`intermediate format need to have an interpreter or virtual
`45 machine capable of interpreting the binary code in the
`intermediate format if the applet is to be executed on the
`client machine.
`In the preferred embodiment, requests to the applet server
`are in a format similar to those of an HTTP header and are
`comprised of tags and values. In one embodiment, an HTTP
`GET method is used to make the request (though use of the
`HTTP protocol is not necessary to implement the present
`invention). The request is made up of a series of tags which
`specify the requested applet, the platform on which it is to
`be run and the type of code (source/intermediate/binary), a
`verification level and an optimization level. New tags and
`values can be added to extend functionality as needed and
`the applet server manager 22 will discard any tag it does not
`recognize. When the applet server computer 10 returns the
`requested applet to the requesting client computer A 12, it
`will transmit the request header followed by the applet code.
`In this instance, the header will additionally include a field
`which defines the length of the applet code. FIG. 2 provides
`a table which illustrates the request format and the returned
`65 code format.
`While this invention has been described with reference to
`specific embodiments, this description is not meant to limit
`
` Exhibit 1024 Page 8
`
` SYMANTEC
`
`

`
`US 6,324,685 Bl
`
`5
`
`15
`
`25
`
`7
`the scope of the invention. Various modifications of the
`disclosed embodiments, as well as other embodiments of the
`invention, will be apparent to persons skilled in the art upon
`reference to this description. It is therefore contemplated that
`the appended claims will cover any such modifications or
`embodiments as fall within the scope of the invention.
`I claim:
`1. A method in a server computer for providing applica(cid:173)
`tions to client computers, the method comprising:
`receiving a request from a client computer, the request 10
`identifying an application and identifying a form of the
`application, the identified form being one of a plurality
`of available forms;
`in response to receiving the request,
`generating the identified form of the application from
`another form of the application; and
`sending the identified form of the application to the
`client computer; and
`caching the identified form of the application so that when
`another request is received for the application in the
`identified form, the identified form of the application 20
`can be sent without regenerating the identified form of
`the application.
`2. A method in a server computer for providing applica(cid:173)
`tions to client computers, the method comprising:
`receiving a request from a client computer, the request
`identifying an application and identifying a form of the
`application, the identified form being one of a plurality
`of available forms; and
`in response to receiving the request,
`when the server computer does not have the application
`in the other form, requesting the application in the
`other form from a computer other than the server
`computer;
`generating the identified form of the application from 35
`another form of the application; and
`sending the identified form of the application to the
`client computer.
`3. A method in a server computer for providing applica(cid:173)
`tions to client computers, the method comprising:
`receiving a request from a client computer, the request
`identifying an application and identifying a form of the
`application, the identified form being one of a plurality
`of available forms; and
`in response to receiving the request,
`generating the identified form of the application from
`another form of the application including when the
`server computer does not have the identified form of
`the application, requesting the application in the
`other form from a computer other than the server
`computer; and
`sending the identified form of the application to the
`client computer.
`4. A method in a server computer for providing applica(cid:173)
`tions to client computers, the m