(12) United States Patent
`Razavi et al.
`
`USOO64O1134B1
`(10) Patent No.:
`US 6,401,134 B1
`(45) Date of Patent:
`Jun. 4, 2002
`
`(54) DETACHABLE JAVAAPPLETS
`(75) Inventors: Behfar Razavi, San Jose; Eric
`Harshbarger, San Francisco, both of
`CA (US)
`(73) Assignee: Sun Microsystems, Inc., Mountain
`View, CA (US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(*) Notice:
`
`(21) Appl. No.: 08/910,481
`(22) Filed:
`Jul. 25, 1997
`(51) Int. Cl. .................................................. G06F 9/54
`(52) U.S. Cl. ........................................ 709/310; 34.5/808
`(58) Field of Search ................................. 345/326-357,
`345/163, 700, 764, 804, 808; 709/200,
`310-332; 707/513
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`6/1990 Atkinson .................... 345/163
`4,931,783 A
`5,742,768 A * 4/1998 Gennaro et al. .....
`... 709/200
`5,802,530 A * 9/1998 Van Hoff .............
`... 707/513
`5,818.445 A * 10/1998 Sanderson et al. .......... 345/334
`5,870,091 A * 2/1999 Lazarony et al. ........... 345/346
`5,923,326 A * 7/1999 Bittinger et al. ............ 345/340
`OTHER PUBLICATIONS
`David Mitchell, Leveraging your Visual C++ experience on
`the Internet with thin client technology, Microsoft Systems
`Journal, v11.n12p47(13), 12/96.*
`
`
`
`Lisa Nadile, “Microsoft expanding OCX: readies detach
`able, embeddable applets for the Internet', PC Week, v13,
`n8, p.6(1) 2/96.*
`Jugel et al; “The Java Telnet applet: documentation”, 1996.*
`Morrison et al, Java Unleashed, 12/96.*
`Afergan et al., Web programming desktop reference, chap.
`14, 1996.*
`Gosling et al., Java API documentation, version 1.0.2, 1996.*
`Jamie Jaworski, JAVA Developer Guide, chapters 1,15,16,
`19.31, and appendix, 1996.*
`Warth et al, User's guide to JDK (beta 1.0): applet; Oct. 24,
`1995.*
`author unknown, Java API documentation, Feb. 22, 1996.*
`* cited by examiner
`Primary Examiner Dung C. Dinh
`(74) Attorney, Agent, or Firm-Blakely Sokoloff Taylor &
`Zafman
`ABSTRACT
`(57)
`A method and System is disclosed for detaching Java applets
`from the constraints of the application Such as a browser
`which provides the Java engine for executing those applets.
`Thus, the applets, when detached, can appear in a detached
`window which is more easily controllable by the operating
`environment desktop. The Java applets continue to run under
`the application's virtual machine but do So without regard to
`the graphical interface limits of the application. Further, if
`the application that launched the applet proceeds to a new
`URL location, the Java applet continues to run. Also, the
`applet, once detached, can be reattached into the application
`to appear in the application history.
`
`20 Claims, 7 Drawing Sheets
`
`APPLICATION
`
`Location: http://www.java.com/...
`
`Picture
`
`410
`
`- Jukebox o
`Radio 00FM
`
`About
`
`Pla (-)-
`
`Stop
`
`Attach
`
`Lenovo Exhibit 1006
`
`Page 1
`
`

`

`U.S. Patent
`
`Jun. 4, 2002
`
`Sheet 1 of 7
`
`US 6,401,134 B1
`
`
`
`
`
`
`
`
`
`
`
`110
`
`Add "Implements
`Detachable" Statement to
`class definition of applet
`
`Implement the interface by
`adding generic methods
`
`120
`
`
`
`
`
`
`
`
`
`
`
`
`
`Are methods
`adequate for
`applet
`"look--feel"
`
`
`
`Modify methods to suit
`look+feel or peculiarities of
`applet
`
`140
`
`FIGURE 1
`
`Page 2
`
`

`

`U.S. Patent
`
`Jun. 4, 2002
`
`Sheet 2 of 7
`
`US 6,401,134 B1
`
`
`
`
`
`Launch applet in virtual
`environment of application
`
`as user activated user
`interface element to
`"detach" applet?
`
`
`
`Cal "Detach"
`
`
`
`
`
`
`
`Re-draw appletin
`application as
`when launched
`
`290
`
`280
`
`Close detached
`window
`
`Call"Attach"
`
`270
`
`Display detached window
`
`Yes
`
`Sg f
`PE ESO
`E.
`WOW
`
`
`
`
`
`
`
`Has user changed
`properties of detached
`window?
`
`Has E. Yi
`user inte face elent
`to "attach" applet back
`to the application?
`
`FIGURE 2
`
`
`
`
`
`
`
`
`
`Page 3
`
`

`

`U.S. Patent
`
`Jun. 4, 2002
`
`Sheet 3 of 7
`
`US 6,401,134 B1
`
`Detached Frame
`Inheritance Hierarchy
`
`Generic Applet
`Inheritance Hierarchy
`
`Object
`
`w
`
`315
`
`d
`
`Object
`
`310
`
`Component
`
`325
`
`Component
`
`320
`
`Container
`
`335 Hierarchy joined
`
`Container
`
`330
`
`Window
`
`Panel
`
`350
`
`Applet
`
`Detached Frame
`
`FIGURE 3
`
`Page 4
`
`

`

`n,vmMDOE
`
`
`
`
`
`...\Eoo.§m_.333\\d§”cosmos
`
`m2395
`m,8v9%
`|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| | x-?i?NOIJLVOITIc{dV
`Dnén
`=----=========-=E20555;?
`
`U.S. Patent
`US. Patent
`
`n.h
`
`m.
`
`4,
`
`4w%
`
`6SU
`
`US 6,401,134 B1
`
`1
`
`1B4
`
`mo;
`
`SEo223m
`
`532moum
`
`Mimi
`Em52?.
`
`om»u
`
`Page 5
`
`Page 5
`
`

`

`U.S. Patent
`
`Jun. 4, 2002
`
`Sheet S of 7
`
`US 6,401,134 B1
`
`
`
`APPLICATION to K
`
`Location: http://www.iava.com/...
`
`About Stop Play Detach
`
`530
`
`550
`
`500
`
`FIGURE 5
`
`Page 6
`
`

`

`U.S. Patent
`
`Jun. 4, 2002
`
`Sheet 6 of 7
`
`US 6,401,134 B1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`60
`
`620
`
`Instantiate new frame
`
`Remove applet
`components from
`application
`
`Add components to
`new frame
`
`630
`
`Add "Attach" user
`interface element to
`new frame
`
`640
`
`Map detached window 645
`onto display device
`
`Inherit application
`characteristics
`
`655
`
`Paint components on 660
`SCCen
`
`FIGURE 6
`
`Page 7
`
`

`

`U.S. Patent
`
`Jun. 4, 2002
`
`Sheet 7 of 7
`
`US 6,401,134 B1
`
`
`
`Remove new frame
`
`710
`
`Add components back
`to application
`
`720
`
`730
`
`Close "kill" detached
`window
`
`Allow reallocation/
`garbage collection of
`memory
`
`4
`740
`
`FIGURE 7
`
`Page 8
`
`

`

`1
`DETACHABLE JAVAAPPLETS
`BACKGROUND OF THE INVENTION
`1. Field of the Invention
`The present invention relates to the field of computer
`Software. More Specifically, the present invention relates to
`applets and their relationship to an operating environment.
`2. Description of Related Art
`Recent versions of applications Such as browsers like
`Netscape Navigator 3.0TM or HotJavaTM (a product of Sun
`MicroSystems, the Sun logo and Hot Java are trademarks or
`registered trademarks of Sun Microsystems in the United
`States and other countries) have provided for the use of
`platform-independent “applets” which can be downloaded
`as pre-compiled Java byte-codes (intermediate level
`instructions). These applets are executed via a “virtual
`machine,” which is a platform-specific environment that
`interprets or compiles the applet code and performs the
`high-level instructions therein. One popular and predomi
`nant applet programming language, developed by Sun
`Microsystems, Inc., is known as “Java"M” (a product of Sun
`MicroSystems, the Sun logo and Java are trademarks or
`registered trademarks of Sun Microsystems in the United
`States and other countries). Applets programmed in Java or
`minor variations thereof are referred to as Java applets.
`The key usefulness of Java applets is that they are
`platform-independent, i.e., a Java applet written for platform
`A will run without modification on platform B provided that
`both platform A and platform B have virtual machines
`capable of executing applet code for their respective plat
`forms. Even though Java applets are platform-independent,
`the characteristics, quirks and limitations of the applications
`from which they are spawned weaken the flexibility by
`causing the applets to become essentially "application
`dependent.” For example, one limitation of Java applets
`when called from HTML (Hypertext Markup Language)
`code for the Sun operating System version of Netscape
`Navigator is that when applets are called, the HTML tag for
`the call must include a height and width, thus defining a
`window size that the applet must execute within. When
`running inside the application window, the applet is con
`Strained by the Stated height and width tag and thus, any
`output, input, dialog boxes or pop-up windows that are
`generated for the applet must appear within that constraint.
`In this situation, where the applet window is a “sub
`window' of the application window, the applet window
`SufferS Several impediments. First, the applet window cannot
`be closed unless the application is quit or until the applica
`tion transitions to receive data from a new host (in the same
`window that launched (spawned) the applet). And concomi
`tant with that limitation, when the application that spawned
`the applet transitions to a new URL (Uniform Resource
`Locator-the “address” of the host visited by the
`application) then the applet window closes and the applet
`ceases execution. The cessation of the applet is out of the
`control of the user. In certain instances, it is desirable to
`continue running the applet even though the application has
`transitioned to a different URL. For instance, a user may
`desire a streaming audio applet that plays content from an
`external or remote source which is launched from URL. A to
`continue playing even though the application has proceeded
`to URL B, which does not have the same applet. Under
`current practice, it would be necessary to open or spawn a
`new instance of the application (i.e., open a new application
`window) to receive its content from URLB so that the other
`application instance continues to play the audio applet. But
`this approach Suffers from Several maladies.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,401,134 B1
`
`2
`First, launching a new application instance may involve
`an increase in memory and System resource utilization
`which will diminish the performance of both the applet and
`the new application instance. Further, the applet Still cannot
`be controlled outside of the constraints or environment of
`the application. In fact, with a Second application window
`(instance) launched, the first window must become active (in
`the foreground, under control of cursor or mouse) before the
`applet can be controlled. Further, the traditional applet
`model does not allow for iconification of the applet window
`within the operating environment (minimizing of the
`window). Under current practice, the application window
`itself must be minimized in order to minimize and iconify
`the applet. In that case, the applet rather than having its own
`icon, will the inherit the icon of the browser. The lack of
`window minimization, resizing and other GUI modification
`Such as changing fonts, backgrounds colors, etc., imposes
`Severe constraints on the applet to be independently con
`trolled without application constraints.
`One Solution to remove the application dependence of
`executable code modules has been the use of "plug-ins”.
`However, unlike “plug-ins' (file(s) containing data/code
`used to alter, enhance, or extend the operation of a parent
`application) that are operating environment/platform
`Specific, Java applets are essentially platform independent.
`Plug-ins, which must be downloaded (or come packaged
`with the application), allow certain file types (Such as
`Shockwave"M or RealAudio"M) which may not be supported
`internally by the application to be interpreted and output on
`the local platform. However, plug-ins are disadvantageous
`in that they remain resident locally and must be stored on
`local disk for re-use, unlike the virtual machine of Java
`which is application resident. Importantly, plug-ins spawn
`processes wholly independent of the browser and are thus,
`platform dependent. Thus, though plug-ins may allow for
`independent GUI control of their windows, they are com
`pletely disinherited from the browser unlike Java applets
`(because they do not require a virtual machine to run).
`Running a plug-in is akin to running a separate application
`via the operating environment, and thus is not a viable
`Substitute for portable executability as is a Java applet.
`Yet another development for enhancing capabilities of an
`application Such as a browser is the use of “helper' appli
`cations. Helper applications, which are Stored locally, do not
`have the portability and platform independence of Java
`applets, i.e., a helper application on a Pentium platform
`cannot be used on a Sun SparcTM (a product of Sun
`MicroSystems, the Sun logo and Sparc are trademarks or
`registered trademarks of Sun Microsystems in the United
`States and other countries) system or Vice-versa. The helper
`application also spawns a new proceSS/thread within the
`operating environment and commands the System resources
`of a new application instance which is unlike Java applets.
`The helper application is not related to the application
`delivering the data to be processed and is merely called
`through the operating environment. The helper application
`does not plug-in or execute within a virtual machine of the
`application. Further, a helper application is not easily trans
`ferred from host to client, Since helper applications can be
`quite large in code size when compared to applets.
`Further, on newer information devices Such as network
`computers (NCs), helper applications and plug-ins may not
`even work due to limited operating environment features
`and lack of local Storage. NCs are conceptually based on
`utilizing remotely Stored applets, Such as Java applets which
`are network distributed, to provide applications and content
`to the NC. In contrast, the current industry standard for NCs
`
`Page 9
`
`

`

`3
`guarantees that NCS are able to execute Java applets,
`through the use of Virtual machine and browser/application.
`Even in the NC situation, it is desirable that the applet have
`its own built-in functionality separate from the browser/
`application from which it is called.
`Thus, there is a need for a method and apparatus to detach
`Java applets from the constraints of the application So that
`they can be GUI-controlled directly through the operating
`environment and so that they not be limited by the state of
`the application in which the applets are Spawned.
`
`SUMMARY
`A method and System is disclosed for detaching Java
`applets from the constraints of the application which pro
`vides the Java Virtual machine for executing those applets.
`Thus, the applets, when detached, can appear in a detached
`window which is more easily controllable by the operating
`environment desktop. The Java applets continue to run under
`the application's virtual machine but do So with leSS con
`Straints than the graphical interface limits of the application.
`Further, if the application that launched the applet transitions
`to a new URL host, the Java applet continues to run. Also,
`the applet, once detached, can be reattached into the appli
`cation to appear in an application history.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a flow diagram of transforming a non-detachable
`Java applet to have the functionality of detachability accord
`ing to an embodiment of the invention.
`FIG. 2 illustrates a flow diagram of applet behavior when
`launched from an application according to an embodiment
`of the invention.
`FIG. 3 is a diagram of exemplary inheritance hierarchy as
`defined for Java applets.
`FIG. 4 is an illustration of a resulting detached applet as
`rendered on a display Screen.
`FIG. 5 shows an applet "Jukebox” in the attached state.
`FIG. 6 is a flow diagram of the detaching of an applet
`according to one embodiment of the invention.
`FIG. 7 is a flow diagram of the attaching of an applet
`according to one embodiment of the invention.
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`Definitions
`The word “operating environment” refers to an operating
`system, kernel, shell, or the like which is low-level software
`which Schedules tasks, allocates Storage, handles the inter
`face to peripheral hardware and presents a default interface
`to the user when no application program is running. The
`operating environment also allows application programs to
`run by performing Storage allocation, input/output, etc., that
`the application may request through its executable code.
`The word “desktop” refers to the visual environment
`(usually output on a display Screen) wherein the operating
`environment allows a user to interact with the operating
`environment. A desktop includes but is not limited to the
`display and use of icons, cursors, windows, dialog boxes,
`menus and other user interface elements which are a func
`tion of the operating environment. The desktop is a visually
`rendered Screen region wherein application windows and
`their associated input/output may be displayed and inter
`acted upon by a user, if desired.
`A“method” as used in the detailed description refers to a
`function call, procedure or routine associated with one or
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,401,134 B1
`
`4
`more classes, which are well-known in the art of object
`oriented programming.
`The word “detachable” refers to the ability of an applet to
`become free of GUI constraints imposed upon it by the
`application that Spawned the applet. "Detachability” implies
`that the applet is capable of being manipulated in a graphical
`user interface Sense Separate of the application that spawned
`it and can instead be manipulated on the desktop by inter
`action directly with the operating environment.
`The word “virtual machine” refers to an interpreter,
`compiler, linker, etc., which is included in an application or
`operating environment to facilitate the execution of
`instructions, pseudo-code and the like for a particular pro
`gramming language Such as Java.
`FIG. 1 is a flow diagram of transforming a non-detachable
`Java applet to have the functionality of detachability accord
`ing to an embodiment of the invention.
`Any pre-existing Java applet can be modified to become
`a detachable Java applet as detachable is described with
`respect to various embodiments of the invention. When an
`applet is defined/created, its Source code can be modified to
`include methods for detaching the applet. The first Step is to
`add an “implements Detachable” statement to the class
`definition of the applet (step 110). This implements an
`interface called “Detachable”. Appendix A, the Java source
`code for the Jukebox Streaming audio applet, shows on
`column 2, the class definition “public class Jukebox extends
`Applet implements Detachable.” The phrase “public class
`<Applet Name> extends Applet” is shared by all applets in
`their main class definition. The phrase “implements Detach
`able' may then be appended to any Such definition to begin
`the modification of the <Applet Name> applet to become
`detachable. Several more Steps are desirable in order to
`complete the foundation for detachability of the applet. The
`Detachable interface invoked via the class definition is
`implemented by adding Several generic "methods” (see
`Definitions, above) to the Source code of the applet (Step
`120). The methods while generic in terms of the Detachable
`Interface are peculiar and unique to this embodiment of the
`invention in that these methods have not been previously
`defined in the art of Java development.
`The generic methods will allow a Java applet to become
`detachable from the application in which they were spawned
`and will allow the applet to have the functionality of any
`ordinary application window running on the operating envi
`ronment (e.g., SolarisTM, a product of Sun Microsystems,
`Solaris is a trademark or registered trademark of Sun Micro
`Systems in the U.S. and foreign countries) desktop. The
`generic methods, if they are not adequate for that specific
`applet’s look-and-feel (checked at step 130), may be modi
`fied. The generic methods can be modified to include
`interfacing that Suits the look-and-feel or peculiarities of the
`applet (step 140). For example, it may be desired in a
`detachable “chat” (text-based conversation between users)
`applet that the chat window resize itself to display long
`strings of text which without resizing itself were invisible.
`The methods, which are defined below may be modified by
`one of ordinary skill in the art to Suit the applet being
`transformed into a detachable applet. One Such modification,
`described below, is the addition of “controller” methods. As
`described with respect to Step 120, these generic methods are
`added to the exemplary Jukebox applet code disclosed in
`Appendix A.
`Generic Detachable Interface Methods and Modifications
`Thereto
`1. “Detach” (illustrated as “public void detach () {” in
`Appendix A).
`
`Page 10
`
`

`

`S
`The Detach method is the primary function call allowing
`the applet to be detached from the application. The State
`variable “isDetached” is set equal to true to indicate the
`applet is now in the detached as opposed to attached State.
`The statement “remove(UIpanel)” is responsible for remov
`ing the "panel” for the user interface which contains com
`ponents like user interface elements (i.e., buttons, text
`boxes, menus, icons, etc.). The panel UIpanel is removed
`and passed onto the "Detached Frame’ class that is instan
`tiated. The “Detached Frame” class is a platform
`independent implementation based on the Standard Java
`Virtual machine and is thus available to all Java platforms.
`Code for the Detached Frame class is shown in Appendix B.
`The Detached Frame is instantiated to create a detached
`window (application independent applet window) into
`which UIpanel components (user interface elements) can be
`rendered. The statement “controller.make Attachable(),” is
`an example of a modification of the generic Detach method
`that is Specific to the Jukebox applet that creates a user
`interface element for attaching the applet back to the appli
`cation.
`2. “Attach” (illustrated as “public void attach () {” in
`Appendix A)
`The Attach method is used to re-attach the applet back to
`the application and to close the detached window residing
`outside of the application's window. The State of the applet
`is returned to attached by Setting isDetached equal to false.
`Next, the Detached Frame object is disposed of. The UIpanel
`components are then added back to the application (add
`(UIpanel) Statement). An example of applet-specific (in this
`case, the Jukebox applet) modification to the generic method
`Attach is the controller, makeDetachable statement which
`when included provides user interface elements for detach
`ing out the applet.
`3. Close (illustrated as “public void close()” in Appendix
`A)
`The Close method kills the Detached Frame window and
`typically, the applet does not thereafter re-attach to the
`application. This method is useful when total purging of the
`applet is desired.
`These generic methods, when added to implement the
`Detachable interface, will cause a non-detachable applet to
`become detachable (have the functionality of detaching from
`the application window).
`FIG. 2 illustrates a flow diagram of applet behavior when
`launched from an application according to an embodiment
`of the invention.
`Though FIG. 2 is directed toward detaching from a
`application, the methodology is equally applicable to
`detaching applets from any environment that executes the
`applet code through a virtual machine.
`According to Step 210, first, the applet must be launched
`in the virtual machine of the application. This is usually
`accomplished automatically when a user Visit a web site
`(HTML page) which includes statement for launching the
`applet. ASSuming that the applet has been transformed
`according to the methodology of FIG. 1, or if the applet is
`already capable of detaching, the Virtual machine is check
`ing (waiting) for the user to activate the user element, Such
`as a button, to detach the applet from the application
`(checked at step 220). If the user has activated the “detach”
`user interface element, then the environment calls the
`“Detach” method (step 230).
`The calling of the “Detach' method, for example, leads to
`the execution of other instructions as mentioned above. One
`key result of these instructions is the displaying of a
`detached window in which the applet controls and perhaps,
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,401,134 B1
`
`15
`
`25
`
`6
`data would be rendered on to (step 240). Two checks are
`continuously being performed once the display has rendered
`the detached window. The first is to see whether the user
`changed properties (such as size, background color, etc.) of
`the detached window (step 255). This step is a check
`performed not from the application, but from the operating
`environment itself. If any changes are requested of the
`properties of the detached window, the operating environ
`ment initiates and completes those changed properties (Step
`250). Such changes include resizing the detaching window,
`changing the fonts of the window, and Since the detached
`window is a window of the operating environment, mini
`mizing and iconification can be performed without
`reference, modification of the application window. Further,
`the applet in the detached window is no longer application
`constrained, and has its own Set of graphical properties
`color, background, font, size, etc.-apart from the applica
`tion. The desktop can control the look-and-feel of the
`detached window, and consequently, to Some degree, the
`applet as well.
`The Second check being performed is to query if the user
`activated the user interface element to attach the applet back
`to application (step 260). Once the applet is in the Detached
`Frame, the user interface element (button, etc.) for detaching
`will be replaced by a user interface element for attaching the
`appletback to the application. A request by the user to attach
`the applet to the application will first cause the “Attach”
`method to be called (step 270). The Attach method includes
`Several instructions as described above but has the primary
`functionality of closing the detached window (step 280) and
`removing it from the operating environment. The applet is
`then redrawn into the application window as when the applet
`was launched maintaining not the detached look-and-feel,
`but reverting to the look-and-feel of the application which
`launched the applet. The applet, when redrawn into the
`application will replace the user interface element for attach
`with the user interface element for detach. Thus, the applet
`can Switch States from attached to detached as the user So
`desires. Not shown in FIG. 2 is the case where the applica
`tion has transitioned to a new host prior to the applet being
`attached. In that case, the applet, rather than being redrawn
`in the application window, becomes part of the application's
`“history'. The history is a record of previously visited URLs
`So that users of the application can return to those URL Sites
`again.
`FIG. 3 is a diagram of exemplary inheritance hierarchy as
`defined for Java applets.
`From object or class inheritance viewpoint, there are two
`sets of inheritance trees for the various embodiments of the
`invention. The first, shown on the right-hand side of FIG. 3
`is the generic Java applet inheritance hierarchy. An Object
`310 is inherited into a Component 320. The Component 320
`(and consequently Object 310) is inherited into Container
`330. Container 330 is inherited into Panel 340. Finally, Panel
`340 is inherited into Applet 350.
`The second hierarchy shown in FIG. 3 is the hierarchy
`created by inheritance of the Detached Frame. This hierar
`chy is a representation of the methodology of detaching an
`applet described with respect to various embodiments of the
`invention.
`Like the generic applet inheritance hierarchy, the left Side
`of FIG. 3, the Detached Frame inheritance hierarchy shows
`an Object 315 inherited into a Component 325. A Container
`335 is, likewise, inherited into a Container 335. FIG. 3
`shows that the two hierarchies are identical up to and
`including the Container object. Thus, the hierarchies may be
`joined at Containers 335 and 330. The joining of the
`
`Page 11
`
`

`

`25
`
`7
`inheritance hierarchy is conceptually the object-oriented
`mechanism allowing an Applet 350 to be transferred from
`the application window to the detached frame Since both are
`instances of class container. One skilled in the art of object
`oriented programming will readily be able to utilize the
`property of joined object hierarchies described above to
`implement the various embodiments of the invention.
`FIG. 4 is an illustration of a resulting detached applet as
`rendered on a display Screen.
`FIG. 4 shows a display 400 which may any monitor,
`display or other visual device that renders a application
`window 410 through the operating environment. Application
`window 410 is shown as an application window which
`contains Several elements Such as a picture and URL
`(Uniform Resource Location) (labeled as “location”), but
`15
`may be any window or display environment running over
`the operating environment. Display 400 shows the applica
`tion window 410 running over an operating environment
`desktop 430 (see above for definition of “desktop”). The
`operating environment desktop 430 and application window
`410 may be more intimately or tightly integrated Such as in
`HotJava ViewsTM (a product of Sun Microsystems, the Sun
`logo and Hot Java Views are trademarks or registered
`trademarks of Sun Microsystems in the United States and
`other countries). The invention can be modified as to remove
`any lingering visual and user interface constraints of the
`application window which may restrain an applet however
`tightly integrated the application and environment may
`Seem. In this Sense, FIG. 4 shows an applet named "Juke
`box” in a detached window 420. The applet was launched at
`Some URL location and initially, contained within applica
`tion window 410 (see FIG. 5). FIG. 4 shows the detached
`State of the applet Jukebox.
`In this detached state, the applet controls “About”, “Stop”
`and “Play” are rendered into the detached window. An
`35
`important aspect to the invention is the ability of the applet
`to continue running or executing its instructions under the
`Virtual machine (interpreter) of the application whose win
`dow is rendered in 410. The operating environment and its
`desktop 430 now controls the general look-and-feel of the
`window for the applet Jukebox. The detached window can
`then be manipulated like any other window on the desktop.
`The application window 410 and the interface properties of
`the application no longer control, constrain or limit the GUI
`characteristics of the applet. Further, when the application
`window 410 transitions to a new host URL, the applet
`continues to run in the Detached Frame. Though the virtual
`machine is platform-dependent, i.e., it must decompose Java
`code into processor/platform native code, the Java applet
`and its code is not. When the application closes all of its
`windows completely, the detached applet is closed as it
`should be. Further, the applet, even though detached, must
`cease execution because it is no longer Streaming data from
`the host that was contacted by the application. Thus, the
`application retains control of concurrently terminating the
`applet when terminating itself even though the applet is
`detached from its windowing and interface constraints of the
`application window.
`While in the detached state, several other GUI modifica
`tions are available to the detached window which are not
`explicitly illustrated. First, unlike traditional applets, a
`detached window 420 can be iconified onto an area of the
`desktop 430 or minimized into a toolbar or other GUI
`element without having to iconify the application window
`410 as well. Thus, the minimized applet can have its own
`icon. Further, the detached window 420 may be resized on
`the desktop 430 while in the detached state without refer
`
`50
`
`55
`
`60
`
`65
`
`US 6,401,134 B1
`
`40
`
`45
`
`8
`ence to the height-width tag within the HTML (Hypertext
`Markup Language) or other document which specified the
`calling of the applet from within the application window
`410. This allows the detached applet greater flexibility in its
`appearance than the non-detachable applet. Further modifi
`cations Such as a change of font type, font size, color,
`background, etc., that are available to other windows run
`ning on desktop 430 are also available for the detached
`window 420 and the applet it displays.
`The detached window 420 contains, in addition to applet
`control for the Jukebox, a “control” (a user interface
`element) is rendered called “Attach” which, when activated,
`will close the detached window 420 and collapse the applet
`back into application window 410. This “Attached” state is
`shown in FIG. 5. If application window had transitioned to
`a new host URL, then the applet is included in the applica
`tion history instead of being instantly executed in the
`application window.
`FIG. 5 shows an applet "Jukebox” in the attached state.
`FIG. 5 also has a display device 500, an operating
`environment desktop 530 and a application win