(12) United States Patent
`Loomans
`
`US0067.28960B1
`(10) Patent No.:
`US 6,728,960 B1
`(45) Date of Patent:
`Apr. 27, 2004
`
`(54) TECHNIQUES FOR MANAGING MULTIPLE
`THREADS IN A BROWSER ENVIRONMENT
`
`(75) Inventor: Jeffrey Loomans, San Francisco, CA
`(US)
`
`. Q3
`-
`(73) Assignee: º Systems, Inc., San Mateo, CA
`
`(*) Notice:
`
`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/437,421
`(22) Filed:
`Nov. 17, 1999
`Related U.S. Application Data
`(60) Provisional application No. 60/109,077, filed on Nov. 18,
`1998.
`(51) Int. Cl." .................................................. G06F 9/00
`(52) U.S. Cl. ....................... 718/102; 709/203; 709/204;
`709/205; 709/206
`(58) Field of Search ......................... 709/102, 200 210,
`709/310, 322; 707/526; 713/1; 718/102
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`5,708,798 A
`1/1998 Lynch et al.
`5,745,765 A
`4/1998 Paseman
`5,825,651 A 10/1998 Gupta et al.
`
`User loads HTML page into : ?
`browser using associated URL º
`
`604-608
`
`602
`
`5,889,990 A * 3/1999 Coleman et al. ............ 709/322
`5,918,239 A * 6/1999 Allen et al. ................. 707/526
`6,128,640 A * 10/2000 Klienman ................... 709/102
`6,175,877 B1 * 1/2001 Zerber ........................ 709/310
`6,256,673 B1 * 7/2001 Gayman ..................... 709/232
`6,415,316 B1 * 7/2002 Van Der Meer ............ 709/203
`6,438,592 B1 * 8/2002 Killian ....................... 709/224
`6,516,338 B1 * 2/2003 Landsman et al. .......... 709/203
`FOREIGN PATENT DOCUMENTS
`::
`
`8/1999
`
`............. G06F/9/44
`
`WO 99.39265
`WO
`* cited by examiner
`Primary Examiner—Meng-Al T. An
`Assistant Examiner—Charles E. Anya
`(74) Attorney, Agent, or Firm—James W. Soong; Siebel
`Systems, Inc.
`ABSTRACT
`(57)
`Techniques for managing multiple threads in an asynchro
`nous environment, such as a browser, are described. As a
`method, instantiating an event thread in response to a user
`event by a shell event handler block that provides shell
`functions for a user event. Once the event thread as been
`instantiated, managing the event thread by a generic thread
`manager block that provides a plurality of multithread
`management functions for the shell event handler. When
`required, blocking and unblocking the event thread by a
`blocking system that is arranged to block and unblock
`threads.
`
`11 Claims, 7 Drawing Sheets
`
`
`
`
`
`-
`
`-
`
`- -
`
`Begin sub-application
`
`|
`ine k
`- -
`-
`Application engine kerne requests
`minimum required subset of
`application components to load into
`browser
`
`&
`URL references and loads
`application engine kernel components H- ":
`into browser
`:
`;
`;
`:
`:
`:
`!
`;
`:
`;
`;
`:
`
`Application engina components run
`any required initialization as well as
`starts request for any additional
`engine components
`
`Concurrently, engine loads initial
`User Interface (UI) components and -----
`data components of the application
`
`604
`
`606
`
`608
`
`
`
`610
`
`
`
`
`
`
`
`to the Ul components
`
`Engine processes the user
`provided inputs in the
`particularized context of the
`data and any application
`specific API extension code
`
`Results are generatid from
`data and additional U? HTML
`pages to respond to user
`
`new sub
`application?
`
`620
`
`Engine loads User Interface
`(UI) components and data
`components of the new sub
`application
`
`
`
`Page 1 of 14
`
`Unified Patents Exhibit 1014
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 1 of 7
`
`US 6,728,960 B1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Page 2 of 14
`
`Unified Patents Exhibit 1014
`
`

`

`US. Patent
`
`Apr. 27, 2004
`
`Sheet 2 0f 7
`
`US 6,728,960 B1
`
`0:65co=mu=anm
`
`28:3no;
`
`5358
`
`mom
`
`NFN.3339.SE
`
`«605205
`
`YVNN
`
`EEEE
`
`mom
`
`EwEmE5
`
`mémm
`
`EwEmE5
`
`NéNN
`
`Em09342...:
`
`mow
`
`8:892as:
`
`cmm
`
`m.9;
`
`Page 3 of 14
`
`Unified Patents Exhibit 1014
`
`Page 3 of 14
`
`Unified Patents Exhibit 1014
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 3 of 7
`
`US 6,728,960 B1
`
`
`
`302
`
`304
`
`226
`
`code segment frames
`
`O O O
`
`data segment frames
`
`O O O
`
`Fig. 3
`
`Page 4 of 14
`
`Unified Patents Exhibit 1014
`
`

`

`US. Patent
`
`A
`
`M
`
`4aehS
`
`7
`
`US 6,728,960 B1
`
`mmw<z<299::
`
`
`
`whzms—Omw<._.<DQZ<
`
`
`
`
`2.vowm02:05:Fzm>mEm:mo...mzoiozE.3me
`M.555oziogm
`
`79umfizcflms£595
`
`M£855%;Em>mE9.
`Eme.9:meEat3:8
`
`NNNmEmcanoo885.5
`mZOEUZDm
`
`«8mhzmzoéooéam83682oz<fizz?
`mQOOm0“.Awm—zéuZmDQEmo<n_wI._._>>Emméém
`
`
`
`
`
`c;\wo<04
`
`nomozmmmmmwzmfizégom8mzoEzE
`
`
`hzm=20mwm0002h<oIO”.
`
`.9:meE0:8:8
`
`8.35::ncmmuou
`
`38:09:00
`
`Page 5 of 14
`
`Unified Patents Exhibit 1014
`
`Page 5 of 14
`
`Unified Patents Exhibit 1014
`
`

`

`US. Patent
`
`m.5
`
`
`
`Acom
`
`w\mmHMm“
`
`79
`
`5
`
`1B
`
`m---2%SEmuo:2%W.---
`
`mcanE9683
`
`
`2umo.Nmmmq
`“a9m«:96.3:
`S:529vaUmomN“685 82:mm9%
`
`
`”a«Em“52.:
`
`
`
`WGas«mamav
`
`
`
`umo.3memcanF395
`
`88—_‘mung
`
`Page 6 of 14
`
`Unified Patents Exhibit 1014
`
`Page 6 of 14
`
`Unified Patents Exhibit 1014
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 6 of 7
`
`US 6,728,960 B1
`
`029
`
`
`
`
`
`*********** * * * - - - - - - - - - - - - * * * * * * * * * * * * * * * * * * *** * * * *
`
`
`
`squauoduloo au?6ue909
`
`909
`
`Page 7 of 14
`
`Unified Patents Exhibit 1014
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 7 of 7
`
`US 6,728,960 B1
`
`
`
`secondary
`storage
`
`708
`
`N processors
`
`702
`
`primary storage
`706
`
`ROM
`704
`
`FIGURE 7
`
`Page 8 of 14
`
`Unified Patents Exhibit 1014
`
`

`

`1
`TECHNIQUES FOR MANAGING MULTIPLE
`THREADS IN A BROWSER ENVIRONMENT
`
`US 6,728,960 B1
`
`2
`while maintaining greater than 99% up time, and finally; 4)
`the Web commerce application must be highly scalable
`given the unpredictable and potentially large number of
`buyers who may simultaneously access the application
`online.
`Conventional attempts to construct general purpose
`e-commerce application include embedded client-side appli
`cations: Java applets, or ActiveX controls. As a class, these
`are generally small programs that can be sent along with a
`Web page to a browser to execute interactive animations,
`immediate calculations, or other simple tasks using the
`computing resources of the client without having to send a
`request back for processing on the server. As an example, as
`shown in FIG. 1, a distributed computer system 100 includes
`a client computer 102 that is coupled to a server (host)
`computer 104. The computer 102 includes a browser appli
`cation 106 that, in turn, includes a requested Web page 108
`having an applet 110 embedded therein capable of perform
`ing various tasks. In most situations, the applet 110 is
`executed by a Java Virtual Machine (JVM) 112 that in this
`example is also resident in the browser 106.
`In order for the JVM 112 to execute the applet 110 the
`applet’s requisite component files (such as “...class files”,
`images and sounds), represented by files 114–118, must be
`downloaded from the server 104 to the JVM 112. Typically
`the server 104 is part of a distributed network of computers,
`such as the Internet, or in some cases could be part of an
`intranet. In any case, the files 114–118 that are required for
`the JVM 112 to run the applet 110 include Java class files as
`well as resource files that are used to support the execution
`of the applet 110. Such class files include a main class file,
`main class 114, that is used by the JVM 112 as an entry point
`for execution of the applet 110. The server 104 also stores
`other class files such as b.class 116 that are used by the JVM
`112 in the furtherance of executing the applet 110. Various
`image and sound components used in the execution of the
`applet 110 are stored in resource files such as c.image 118.
`In order for the JVM 112 to execute the applet 110, it may
`be required to download some of the class and resource files
`as needed. This is typically accomplished by sending a file
`request that takes the form of an HTTP request to the server
`104 which responds by providing the requested file. By way
`of example, the JVM 112 issues a request to retrieve the
`main class file main.class 114 to which the server 104
`responds by sending (i.e., downloading) the requested file
`(i.e., main.class 114). This request/response procedure is
`followed for every file for which the JVM 112 requires to
`execute the applet 110.
`As can be readily appreciated, the Java applet approach is
`not highly interactive since in general it may require a
`substantial amount of time to download the JVM and will
`require time to download needed class files before the applet
`can even initiate. In addition, no particular provision is made
`to segment application specific applet code as problem
`complexity grows. Thus, the larger and more complex the
`e-commerce problem, the larger and slower the initial down
`load prior to user interaction. Finally, since there are a large
`variety of JVMs and class files available, and since Java is
`unstable on many client machines, making a Java based
`applet robust across all or even most users would require
`many hundreds of thousands of bytes to be downloaded
`across the Internet. These large data transfers would be
`counterproductive to producing the highly interactive expe
`rience desired by the e-customer. Therefore, in order to
`improve the interactivity of the applet (by reducing the size
`of the data transfers), the robustness of the applet would be
`adversely affected since some platforms would not be effec
`tively serviced.
`
`10
`
`15
`
`20
`
`30
`
`35
`
`25
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`This application claims benefit of priority under 35 U.S.C.
`$119(e) of U.S. Provisional Application No. 60/109,077
`filed Nov. 18, 1998, and entitled “Leveraging the Web:
`Architechture Matters” which is hereby incorporated by
`reference. This application is also related to co-pending U.S.
`Pat. No. 6,393,605 B1 issued May 21, 2002, and entitled
`“Apparatus and System for Efficient Delivery and Deploy
`ment of an Application” and co-pending U.S. Pat. No.
`6,549,908, B1 entitled “Methods and Apparatus For Inter
`preting User Selections in the Context of a Relation Dis
`tributed as a Set of Orthogonalized Sub-Relations”, filed
`simultaneously herewith, which is assigned to the assignee
`of the present application and is incorporated herein by
`reference in its entirety.
`BACKGROUND OF THE INVENTION
`1. Field of Invention
`The invention relates generally to computer systems.
`More particularly, methods and apparatus for providing
`highly interactive, robust, and scalable on-demand network
`application delivery and execution capabilities in a distrib
`uted computer network are disclosed.
`2. Description of Relevant Art
`Generally speaking, a browser is an application program
`that provides a way to look at and interact with information
`on distributed computer networks such as the Internet. In
`particular, a Web browser is a client program that uses the
`Hypertext Transfer Protocol (HTTP) to make requests of
`Web servers throughout the Internet on behalf of the browser
`user. One of the most recent uses of browsers is in the realm
`of electronic (e-) commerce in which any number of client
`side users (i.e. “e-customers”) interact in a real time basis
`with any number of server side processors (i.e., “e-sellers”)
`over the Internet. In order to transact business in a Web
`40
`based environment, browsers typically execute Web com
`merce applications specifically designed to facilitate
`e-commerce transactions such as requesting quotes, select
`ing options and assembling components into complex
`bundles, and placing orders.
`In this regard, successful Web commerce applications
`must be capable of automating a customer through the entire
`buying cycle, from initial inspection to final purchase and
`shipping, in addition to providing the customer all relevant
`information required to make a buying decision and provid
`ing customer guidance. As the complexity of the buying
`cycle and/or the purchases themselves increases—for
`instance, from buying office supplies to buying mainframe
`computers—a general purpose Web commerce application
`must scale its ability to manage this complexity. In order to
`accomplish this, a general purpose Web commerce applica
`tion must be: 1) fast loading and highly responsive in “click
`over click” type scenarios in order to support highly inter
`active customer sessions such that a buyer can input any and
`all relevant information quickly and with apparently little or
`no delay in application response; 2) powerful in its ability to
`process relevant data from a broad range of possible choices,
`configurations, and problem domains quickly—in other
`words, a general purpose Web commerce application should
`have the flexibility and computational power of a conven
`tional programming language; 3) the application must be
`robust in that it can run on a wide variety of client machines
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Page 9 of 14
`
`Unified Patents Exhibit 1014
`
`

`

`3
`Another conventional approach to delivering general pur
`pose e-commerce applications is referred to as server side
`processing. In server side processing, all application pro
`cessing is performed on the server and does not use the
`computer resources of the client. In this way, the problems
`related to initial load time and robustness are solved.
`However, this comes at the cost of interactivity since the
`servers are physically separated from the clients in a dis
`tributed network of computers such as the Internet. Even
`with the advent of broadband access, the performance of a
`server side application will always be generally slower than
`an equivalent client side application simply because each
`interaction, processing, and response cycle requires the
`physical transfer of requests across a network that is subject
`to congestion, transfer failure, and communication over
`head.
`In addition to speed considerations, it is difficult to find a
`general solution to scaling the server side facility since every
`time a new user is added, additional processing capabilities
`must be provided by the server. In the general access
`environment of the Internet, unpredictable end-user demand
`can cause sudden usage spikes, or can simply grow to
`overwhelm available server resources. Finally, since thou
`sands of even millions of clients share the same network of
`server side processing resources, errors in or changes to the
`application run the very real risk of simultaneously shutting
`out all users, causing potentially large losses of time and
`revenues. Generally, a client side solution can avoid these
`problems by distributing processing out to each client’s
`machine.
`Finally, it is in principle possible to develop and deliver
`to each end user’s machine code that is custom written for
`the particular combination of browser, platform, and
`e-commerce application. However, this is not a general
`purpose solution, as it cannot realistically be expected that
`the many millions of e-commerce applications running on
`their respective browsers can be truly customized within a
`reasonable length of time.
`In addition to the above described shortcomings of the
`conventional approaches to delivering general purpose
`e-commerce application, asynchronous loading of data and
`code segments requires that any generic application engine
`must provide a generic layer for management of thread
`states and signaling of initiation and termination.
`Since conventional browsers do not provide the requisite
`thread management routines, therefore, what is desired are
`techniques for providing reentrant threading in an asynchro
`nous environment, such as that of a browser.
`SUMMARY OF THE INVENTION
`Techniques for managing multiple threads in an asynchro
`nous environment, such as a browser, are described. In one
`embodiment of the invention, a method is disclosed. An
`event thread is instantiated in response to a user event by a
`shell event handler block that provides shell functions for a
`user event. Once the event thread as been instantiated, the
`event thread is managed by a generic thread manager block
`that provides a plurality of multithread management func
`tions for the shell event handler. When required, the event
`thread is blocked or unblocked by a blocking system that is
`arranged to block and unblock threads.
`In another embodiment, a computer program product for
`managing multiple threads in a browser program executing
`on a client platform is disclosed. The computer program
`product includes computer code that instantiates an event
`thread in response to a user event by a shell event handler
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,728,960 B1
`
`4
`block that provides shell functions for a user event and
`computer code that manages the event thread by a generic
`thread manager block that provides a plurality of multithread
`management functions for the shell event handler. The
`computer program product further includes computer code
`that blocks and unblocks the event thread when required. In
`a preferred embodiment, the computer code is stored in a
`computer readable medium.
`In yet another embodiment, an apparatus for managing
`multiple threads in a browser program executing on a client
`platform is disclosed. The apparatus includes software
`means for instantiating an event thread in response to a user
`event by a shell event handler block that provides shell
`functions for a user event and software means for managing
`the event thread by a generic thread manager block that
`provides a plurality of multithread management functions
`for the shell event handler. The apparatus also includes
`software means for blocking and unblocking the event
`thread when required.
`BRIEF DESCRIPTION OF THE DRAWINGS
`The invention, together with further advantages thereof,
`may best be understood by reference to the following
`description taken in conjunction with the accompanying
`drawings in which:
`FIG. 1 shows a conventional distributed computer system
`capable of supporting a Java based applet browser/server
`configuration.
`FIG. 2 shows a browser/server system in accordance with
`an embodiment of the invention.
`FIG. 3 shows one implementation of a hidden frameset in
`accordance with an embodiment of the invention.
`FIG. 4 shows one implementation of an application
`engine kernel in the form of a block diagram is shown in
`accordance with an embodiment of the invention.
`FIG. 5 shows a timing diagram illustrating an application
`engine asynchronously loading both code and data segments
`in accordance with an embodiment of the invention.
`FIG. 6 shows a flowchart detailing a process for deliver
`ing and deploying an application in a browser in accordance
`with an embodiment of the invention.
`FIG. 7 illustrates a computer system that can be employed
`to implement the present invention
`DETAILED DESCRIPTION OF THE
`EMBODIMENTS
`In the following description, frameworks and methods of
`providing an apparatus and system for efficient delivery and
`deployment of an application within, for example, a
`browser/server environment are described. Although the
`invention will initially be described in terms of a
`multithreaded, object oriented computing system imple
`mented using HTTP requests and responses, it should be
`noted that the present invention can be used in any system
`that is capable of handling well defined requests and
`responses across a distributed network.
`It should be noted that although the invention is described
`in terms of the Internet, any distributed network can be
`suitably employed to implement any desired embodiment of
`the invention. It is one of the advantages of the invention that
`it is well suited for low bandwidth systems capable of
`executing client side applications. Such low bandwidth
`systems include, but are not limited to: virtual private
`networks direct serial connections across telephone lines
`(“BBS systems”), and LANs and WANs regardless of net
`work protocol.
`
`Page 10 of 14
`
`Unified Patents Exhibit 1014
`
`

`

`US 6,728,960 B1
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`5
`When implemented in a network using the HTTP
`protocol, such as the Internet, when an end user (i.e., client)
`desires to run an application within a browser environment,
`the end user generates an HTTP request for a resource
`identified by a URL (universal resource locator). In one
`implementation, this request is transmitted by way of a
`distributed network, such as the Internet, to a server com
`puter.
`In response to the URL, the server computer provides an
`HTTP response in the form of an HTML page generally
`consisting of the “expected” interface page and an embed
`ded application engine kernel. In a preferred embodiment,
`the web page is an HTML frameset that transparently
`contains the expected interface page(s) in one frame, and the
`engine kernel frameset in another. The kernel is the mini
`mum subset of components required to process and display
`the initial expected interface pages once loaded. In general,
`the kernel undergoes bootstrapping in that it initially loads
`in only enough of itself sufficient to load the next larger
`kernel set, which, in turn, has the capacity to load additional
`components, and so forth until all components that are
`required for initial processing of user requests are present.
`Typically, the kernel includes, for example, JavaScript code
`to provide basic thread management functions. These
`include, but are not limited to, event handling routines,
`blocking functions, structures (such as frames) within which
`application components such as data and additional code
`may be loaded later, if required. Typically, the initial kernel
`components also include initialization sections and sections
`allowing the loading of additional engine components not
`required at startup.
`Concurrently with the kernel bootstrapping, the applica
`tion shell page loads initial GUI components and data
`components. Once all required load time components are
`available, the application engine can then proceed in pro
`cessing user supplied inputs in the particularized context of
`the received data and any API extension code during what is
`referred to as a sub-application. In the described
`embodiment, results of the particularized processing are
`then displayed (if required) using, for example, additional
`HTML pages. It should be noted that in almost all cases, a
`user session will consist of a series of different sub
`applications as, for example, a user navigates the application
`interface and interacts with the different sections each with
`its own particularized UI and data. When a new sub
`application is required, during what is referred to as a
`“demand load”, the kernel’s thread manager oversees the
`asynchronous accessing and loading of the sub-application’s
`additional UI and data files by the browser, and potentially
`the asynchronous accessing and loading of additional engine
`code components. It is important to note that the thread
`manager must be capable of “blocking”, or pausing execu
`tion of the application, while monitoring the multiple pro
`cesses loading in new components, and restarting or
`“unblocking” the application when all are complete.
`It is during such asynchronous demand loads in a multi
`threaded environment that various thread management
`schemes are provided by the kernel, as the browser itself
`provides neither support for multiple processes, nor for
`management of concurrent threads. In contrast to conven
`tional browser configurations, this independence of kernel
`from browser enables the inventive kernel to provide multi
`thread management so as to be capable of supporting
`concurrent thread execution in a browser environment.
`Using the inventive application engine and deployment
`methods, therefore, regardless of the particularized UI and
`data required for a given application, only the minimal set of
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`required components is ever loaded onto the client, and all
`processing of user inputs and calculation results is carried
`out on the client platform without resorting to server side
`processing. As a generic solution, the invention thereby
`assures the highest possible interactivity in a distributed
`network environment as well as significant scaling
`advantages, as all processing resources are provided by the
`client.
`Furthermore, the generic engine is independent of both
`browser and platform, and of particularized components
`required by any given application, so robustness across the
`breadth of client systems and the power to handle even
`complex problems is provided without requiring, for
`example, customized coding.
`The invention will now be described in terms of a browser
`resident in a client computer that is typically used to execute
`a highly interactive e-commerce application. It should be
`noted, however, that any applications requiring data pro
`cessing in a highly interactive environment can also be
`implemented using the invention, and the invention there
`fore should not be construed as being limited to e-commerce
`applications. It should also be noted, that the invention is
`well suited for any low bandwidth system in which user
`interactivity is a prime consideration.
`Referring now to FIG. 2, a browser/server system 200 in
`accordance with an embodiment of the invention is shown.
`The system 200 includes a client computer 202 coupled to
`a server (host) computer 204. Typically, the host computer
`204 is part of a distributed interconnected computer network
`205 such as the Internet, but can also be part of a private
`wide or local area network (WAN/LAN) utilizing HTTP
`protocols, sometimes referred to as an intranet. It is one of
`the advantages of the invention that the interconnected
`computer network can be any low bandwidth system.
`In order to facilitate communication between the various
`users and/or computers that form the network 205, the client
`computer 202 utilizes the graphical user interface resources
`presented by a Web page (sometimes referred to as an
`HTML page) 206 resident in a browser 208, most of which
`are obtained by various HTTP requests. When a user desires
`to download a particular HTML page 206 from the server
`204, the browser 208 generates an HTTP request 212. The
`URL for the requested page 206 includes information related
`both to the location of the server computer 204, and to the
`location within the server computer 204 where the page 206
`is located.
`In contrast to conventionally configured HTML pages, the
`particular “shell” HTML page 206 is a frameset formed of
`a visible HTML page 214 and an associated frameset 216
`that acts as a loader causing all components of the applica
`tion engine to download to the browser 208 by way of an
`HTTP response 220.
`In the described embodiment, the frameset 216 defines an
`application engine 218 to include all required loadtime
`components that are ultimately incorporated into the
`browser 208 as a kernel 222. As initially loaded, the kernel
`222 is a primitive kernel that determines the browser class
`of the browser 208. In the described embodiment, the kernel
`222 is formed of code that is generally script embedded in
`HTML, such as Javascript or VB script. As is well known by
`those skilled in the art, since each browser belongs to a
`particular browser class, each of which can execute this code
`differently, it is important to quickly determine the particular
`browser class to which the browser 208 belongs. In this way,
`the primitive kernel can replace itself with a browser specific
`kernel in the form of the kernel 222. Thereafter, kernel 222
`
`Page 11 of 14
`
`Unified Patents Exhibit 1014
`
`

`

`7
`will be responsible for loading additional components
`required during a particular user session.
`It should be noted that the kernel 222 includes that code
`required to provide thread management functions such as
`event handling and thread blocking, and appropriately con
`figured data structures and frames that will contain addi
`tional code and data components. For example, in some
`implementations, the kernel 222 initiates and monitors load
`time threads that are used, for example, to specify those user
`interface (UI) files are to be loaded to form various UI
`interface elements 224-1 through 224-3. It should be noted
`that the application engine 218 interprets which files which
`will be loaded for the associated application, or appropriate
`sub-application, as well as how data will be used to fill in
`each of the particular UI interface elements 224-1 through
`224-3. For all subsequent demand-loads of sub-applications,
`the kernel 222 included in the application engine 218
`provides all necessary and appropriate event handler rou
`times in order to properly manage concurrent asynchronous
`threaded operations, such as demand loading of additional
`application engine components and data components.
`In the described embodiment, the code and data segments
`loaded by the kernel 222 are stored in what is referred to as
`a hidden frameset 226 (hidden since the user cannot “see”
`the results of these loads as visible HTML pages). One
`implementation of the hidden frameset 226 in accordance
`with an embodiment of the invention is shown in FIG. 3. In
`the implementation shown, the frame structure 226 includes
`n generic engine code segment frames 302 and m applica
`tion specific data segment frames 304 that are each logically
`and physically separate from one another and from the
`browser 208. It is important to note that for a particular
`application the n generic engine segment frames 302 are
`“locked” in that once loaded each of the particular n code
`segments cannot be modified or replaced. However, as one
`might expect, the m application specific frames 304 can be
`updated as necessary. This provides a standard, generic
`engine reference environment across all particular applica
`tions.
`Referring back to FIG. 2, once loaded, the kernel 222
`included in the application engine 218 performs a bootstrap
`operation by running any required initialization routines as
`well as concurrently retrieving any further application
`engine components known to be required at startup. Once
`the initialization routines have been successfully completed,
`the application engine 218 is ready to begin processing user
`inputs via selected ones of the interface pages 224-1 through
`224-3 in the particularized context of the data components in
`the frameset 226 and displaying, where appropriate, the
`result(s) in additional HTML pages generally in the visible
`frame 214.
`Referring now to FIG. 4, one implementation of the
`kernel 222 in the form of a block diagram is shown in
`accordance with an embodiment of the invention. In the
`described embodiment, the kernel 222 includes a function
`block 402 that enhances the robustness of the application by
`providing primitive functions that guarantee the presence of
`the kernel 222 and associated application engine compo
`ments in frameset 226. Typically, the function block 402 is
`called from engine code segments and interface components
`both to centralize demand loads of missing components and
`to handle cases of incorrector missing components. Another
`function block 404 called from external interface compo
`ments (such as, for example, API calls) provides shell
`functions for user event handling. It is important to note that
`the kernel, and more importantly, the shell event handlers
`included in the kernel are logically separate and distinct both
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,728,960 B1
`
`8
`from the browser 208 and from the particular sub
`application routines in the frameset 226 called from the shell
`routines.
`It is important to have independent shell event handlers in
`the kernel since in the absence of browser provided thread
`management routines, a generic application engine must
`provide a generic layer for management of thread states and
`signaling of initiation and termination. In this way, thread
`manager block 406 provides various thread management
`functions for general shell event handlers. These handlers
`can then, in turn, call application specific handlers for
`particularized application data without having to custom
`develop thread management code for each particularized
`application.
`For an example of the general process of managing
`multiple threads of execution and loading sub-applications,
`refer to FIG. 5 which is a timing diagram 500 illustrating an
`application engine asynchronously loading both code and
`data segments in accordance with an embodiment of the
`invention. As shown in FIG. 5, at an initial time t, code
`segment 502 has been loaded by the kernel 222 prior to a
`user event 504 such as clicking or unclicking a UI element
`(for instance, a button o