United States Patent (19J
`Shaw et al.
`
`I lllll llllllll Ill lllll lllll lllll lllll lllll 111111111111111111111111111111111
`US006104392A
`(11] Patent Number:
`(45] Date of Patent:
`
`6,104,392
`Aug. 15, 2000
`
`(54] METHOD OF DISPlAYfNG AN
`APPLICATION ON A VARIETY OF CLIENT
`DEVICES IN A CLIENT/SERVER NETWORK
`
`5/1998 Bulls et al. ............................. 370/466
`5,754,830
`8/1998 Esbensen ................................ 709/207
`5,796,942
`5,999,882 12/1999 Simpson et al . ............................ 702/3
`
`(75]
`
`Inventors: Andrew Shaw, West Yorkshire; Karl
`Richard Burgess, Barnsley; John
`Marcus Pulla n, Ilkley; Peter Charles
`Cartwright, Leeds, all of United
`Kingdom
`
`(73) A5.5ignee: The Santa Cruz Operation, Inc.,
`Santa Cruz, Calif.
`
`(21) Appl. No.: 09/190,757
`
`(22) Filed:
`
`Nov. 12, 1998
`
`Related U.S. Application Data
`(60) Provisional application No. 60/065,521, Nov. 13, t 997.
`Int. C l.7
`............................................. ... ... ... .. G06F 7/00
`(51)
`(52] U.S. CJ. ........................... 345/335; 709/W7; 345/329
`(58] Field of Search ..................................... 345/328, 333,
`3451335, 346, 356; 709/2'17, 224, 229,
`311
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`OTHER PUBLICATIONS
`
`The Santa Cruz Operation Technical White Paper, Taran(cid:173)
`tella - The Universal Application Server, Jul. 1997.
`
`Primary Examiner-Raymond J Bayerl
`Assistant Examiner-Cao H. Nguyen
`Attorney, Agent, or Firm- Wilson Sonsini Goodrich &
`Rosati
`
`[57]
`
`ABSTRACT
`
`lo a client-server architecture, an Adaptive Internet Protocol
`(AIP) system, comprised of a display engine operating on a
`server and a protocol engine operating on a server, provides
`means to support standard graphics based computer appli(cid:173)
`cations connected to clients of varying capability via a
`network of varying bandwidth and latency by automatically
`varying the type and number of graphic requests and their
`networking encoding to provide near optimum performance
`while maintaining the correct visual representation.
`
`5,740,801
`
`4/1998 Branson .................................. 709/311
`
`34 Claims, 6 Drawing Sheets
`
`276A
`~~
`Stondord Netwo rk
`0 isp loy Protoco I
`:':!~_[310
`r -- - ------- -------
`I
`: Cf TRl<l init 1, process opplicotioo dis;iloy request
`I
`! rc,-.,-t,-Sc'-re-eo_Im_ge~....-Step 2
`I
`I
`I
`1 & Store io Meoory
`I
`I
`1
`I
`I
`
`Convert Disp lay
`Reque st
`
`Step 3
`Step 4
`
`j
`
`Network
`Connec t ion
`
`IPR2017-00184
`UNIFIED EX1008
`
`

`
`BO-
`
`UNI X
`X Windows
`82A
`
`Windows
`NT
`
`UNIX & IBM
`Character App licat ions
`82B
`Application Services 82
`82D
`
`82C
`
`82E
`
`Terminal Emulator Web Server
`64 66
`62
`
`X Eng ine
`
`70
`Session Manager Eng ine
`52
`54
`X I nterface
`Character based Interface
`
`~ •
`00
`•
`
`Di rec to ry
`Service s
`
`Databa s e
`Servers
`
`82F
`
`LDAP
`
`50
`
`UAP Server
`
`60
`
`40
`
`30
`
`10---
`
`16
`
`12
`
`C lient Con nections
`
`Java V i rtual Machine
`
`14A
`
`'------~Admini st rat i on &
`Ma nagemen t
`
`56
`
`72
`
`20
`
`Admin istration
`
`18
`
`Web B rowse r
`f 4C Th in C I i en t
`14D~
`14 /;§)
`CI ien t Dev ices
`
`FIG. 1
`
`

`
`U.S. Patent
`
`Aug. 15, 2000
`
`Sheet 2 of 6
`
`6,104,392
`
`282A
`282C
`2828
`r.--- ---------- ---------- ---,
`280
`I X Windows
`Character-based
`I
`Windows
`2a2---1!~~~a ~~-=---~~~ca~~~s----~~l~ca ~~~J
`PS
`P4
`
`P3
`
`250
`
`r272
`Administrative··· ··································· ................... .
`Eng ine
`······································
`271
`Data
`Store
`Engine
`
`Status Session
`Manager Manager
`Engine Engine
`
`270
`
`276A
`
`Protoco l
`Engines
`
`1---11--+-~
`
`276B
`
`276C
`
`274
`
`' ' ' ' ' ' ' ....
`' p5J',
`' ' ' ',
`
`264
`.. Web Server
`
`251
`
`253
`
`'
`---- - ---- - -<'"'-~ ~
`
`', ' ' ~'··· · lllrr.··· '
`255
`;
`255A
`255B
`
`P1
`
`P2
`
`I
`
`i
`
`P10
`L ____ _ _ -:\_ ___ _ _ __ ___ 1
`
`I
`278.4
`
`278B
`278C
`
`225
`
`225C
`
`Web t op
`223
`Log in App let ----
`
`Boot- strap
`221 App let
`
`Web Browser
`
`218
`
`214
`
`FIG.2
`
`

`
`U.S. Patent
`
`Aug. 15, 2000
`
`Sheet 3 of 6
`
`6,104,392
`
`Standard Network
`D i splay Request
`
`312
`
`r - - - - - - - - - - - - - - - - - - - - -- -,
`276A
`
`Request
`Trans fo rmat ion
`a nd
`Costing
`Pro cess
`
`310
`
`278A
`
`370
`
`350
`
`360
`
`320
`
`330
`
`Request
`Optimizat ion
`a nd
`Encod i ng
`Process
`
`~-- - -
`
`Performance
`Monitor i ng
`and TRQ
`Updat in g
`Process
`
`Graph ics
`Disp lay
`and
`Upda t e
`Process
`
`I
`I
`I
`I
`-- ------ -- - -- --- ---~- ----
`P7
`
`FIG.3
`
`

`
`U.S. Patent
`
`Aug. 15, 2000
`
`Sheet 4 of 6
`
`6,104,392
`
`276A
`~
`Standard Network
`D isp lay Pro toco l
`r --- ----- - - ---- ---
`: If TRT<Limit 1, process app lication display request
`I
`Ste 2
`I Create Screen Image
`P
`I &: Store in Memory
`Step 3
`Step 4
`I
`I
`Request Re lat ive Cos ts
`- -=--=--=--=--=-
`-=--=--=--=--=--=--=--=--=-1
`I
`
`~tep ~-[310
`I
`I
`I
`I
`I
`I
`I
`I
`I
`..J
`
`Convert Display
`Reques t
`
`278A
`
`r -
`RSN
`I
`I Generation
`I
`1.----s-e._n_d-..
`I
`RSN
`[ ___ _
`I
`
`Execute
`Request
`
`Step 16
`
`RLE
`Expans ion
`
`Delta
`Expansion
`
`De lt a
`Compr ess ion
`
`FIG.4
`
`

`
`U.S. Patent
`
`Aug. 15, 2000
`
`Sheet 5 of 6
`
`6,104,392
`
`Request
`AIP_NOOP
`AIP_PUTIMAGE
`AIP_SETCOLORS
`AIP_POLYLINE
`AIP_POLYSEGMENT
`AIP_POLYRECTANGLE
`AIP_POLYFILLRECT
`AIP_FILLPOLYGON
`AIP_COPYAREA
`AIP_POLYGON
`AIP_SETCURSOR
`AIP_CREATEWINDOW
`AIP_DESTROYWINDOW
`AIP_SHOWWINDOW
`AIP_CONFIGUREWINDOW
`AIP_SETDRAWABLE
`AIP_SETFGCOLOR
`AIP_SETBGCOLOR
`AIP_SETROP
`AIP_SETTILE
`AIP_SETSTIPPLE
`AIP_SETTSORIGIN
`AIP_SETFILLSTYLE
`AIP_CREATEPIXMAP
`AIP_DESTROYPIXMAP
`AIP_SETFILLRULE
`AIP_SETFONT
`AIP_SETPLANEMASK
`AIP_POLYTEXT
`AIP_IMAGETEXT
`AIP_CREATEFONT
`AIP_DESTROYFONT
`AIP_CREATEGLYPH
`AIP_SETGLYPH
`AIP_DESTROYGLYPH
`AIP_SETHINTS
`AIP_REQPERFINFO
`AIP_COPYPLANE
`
`Sample AIP Requests
`
`Description
`
`No ope rat ion
`the server to the display
`Transfer bitmap from
`Change
`the color mapping
`tab le
`Draw a series of joined
`lines
`Draw a series of un-joined line segments
`Draw a series of outline rectangles
`Draw a ser 1es of f i I led rectangles
`Draw a sing le
`f i I led polygon
`Copy a rectangular area of the display
`Draw a sing le closed polygon
`Change
`the mouse pointer
`Create a rectanglar graphics window
`Destroy a graphics window
`Display/remove a graphics window
`Change a graphics windows attributes
`Switch the destination for graphic operations
`Change
`the foreground drawing color
`Change
`the background drawing color
`Set the graphics raster operation
`Set
`the title for fill operations
`Set the stipple for fill operations
`Set the Tile/Stipple or1g1n
`Set the graphics f i 11
`type
`Create an 1n memory graphics surface
`Destroy an 1 n memory graphics surface
`Set fill rule for ploygon fills
`Set the font for text output
`Set the p lanemask for graphics operations
`Draw a series of characters without background
`Draw a series of characters with background
`Create a font for text output
`Destroy a text font
`Create a series of text glyphs
`Change a text glyph
`Destroy a text glyph
`Set drawing cont r o I at tr i but es
`Request new performance
`information
`Copy a sing le bit-plane
`
`FIG.5
`
`

`
`U.S. Patent
`
`Aug. 15, 2000
`
`Sheet 6 of 6
`
`6,104,392
`
`Table 1
`Sample Request Trans lat ions
`
`Explanation
`
`Simple polyline requires only
`foreground co !or
`
`AIP Requests
`X11 Windows Request
`ChangeGC - Set AIP_SETFG
`Foreground Color AIP_POLYLINE
`Po!yline
`ChangeGC - Set AIP_POLYSEGMENT Dashed
`lines are drawn as a
`dashed I ine sty le
`series of I ine segments
`r='o !y I ine
`ChangeGC - Set I ine AIP_POLYFILLRECT Wide
`lines are drawn as a series of
`width to 10 Polyline
`f i I led rec tang !es
`ChongeGC - Set Solid AIP_SETFILLSTYLE Simple f i 11 request
`Fi 11 Po lyF i I IRec t AIP_POLYFILLRECT executed directly
`ChongeGC - Set Tiled AIP_SETFILLSTYLE Difficult fill operation. Not ab le
`Fi 11 Po lyF i I IRec t AIP_SETTILE
`to draw di re ct ly. Fi 11
`to memory
`AIP_SETTSORIGIN
`based screen and perform update
`AIP_POLYFILLRECT
`to display
`AIP_SETHINTS
`
`Request
`
`AIP_PUTIMAGE
`AIP_SETCOLORS
`AIP_POLYLINE
`AIP_SEGMENT
`AIP_POLYRECTANGLE
`AIP_POLYFILLRECT
`AIP_FILLPOLYGON
`AIP_COPYAREA
`AIP_POLYGON
`AIP_POLYTEXT
`AIP_IMAGETEXT
`AIP_COPYPLANE
`
`Table 2
`Sample Relative Request Costs
`Estimated Request Time (µs)
`Relative Request Costs
`Per Pixel
`Basic
`Per Pixel
`Basic
`
`0 .2000
`0 .0040
`0 .2000
`0 .2000
`0 .2700
`0 .0270
`0 .2100
`0 .0400
`0 .1600
`0 .4000
`0 .2100
`0 .0400
`
`50 .0000
`30 .0000
`74 .5000
`74 .5000
`29 .3000
`38 .7000
`243 .7000
`35 .8000
`74 .5000
`2 .5200
`2 .5200
`35 .8000
`FIG.6
`
`0 .0219
`0 .0004
`0 .0219
`0 .0219
`0 .0295
`0 .0030
`0 .0230
`0 .0044
`0 .0175
`0 .0437
`0 .0230
`0 .0044
`
`5 .4651
`3 .2790
`8 .1430
`8 .1430
`3 .2025
`4.2300
`26 .6368
`3 .9130
`8 .1430
`0 .2754
`0 .2754
`3 .9130
`
`

`
`6,104,392
`
`1
`METHOD OF DISPLAYING AN
`APPLICATION ON A VARIETY OF CLIENT
`DEVICES IN A CLIENT/SERVER NETWORK
`
`CROSS-REFERENCE TO RELATED
`INVENTIONS
`
`The application is based on the provisional application
`entitled "The Adaptive Internet Protocol System" filed Nov.
`13, 1997, serial number 60/065,521.
`
`STATEMENT REGARDING FEDERALLY
`FUNDED RESEARCH
`
`Not Applicable
`
`REFERENCE TO A MICROFICHE INDEX
`
`Not Applicable
`
`COPYRIGHT NOTICE
`
`Copyright 1997 The Santa Cruz Operation, Inc. A portion
`of the disclosure of this patent document contains materials
`which are subject to copyright protection. The owner has no
`objection to the facsimile reproduction by anyone of the
`patent document or patent disclosure, as it appears in the
`Patent and Trademark Office patent file or records, but
`otherwise reserves all rights, copyright rights whatsoever.
`
`BACKGROUND OF THE INVENTION
`
`20
`
`2
`needs on the desktop client: configuration, security, access
`control, mobility. The information services department pro(cid:173)
`vides this by administering each client separately. If remote
`offices are involved, costs to do this increase significantly.
`5 Performance in this heterogeneous client network must also
`be maintained. Slow performance takes up time and money.
`Networks vary in bandwidth, e.g. modem links, ATMs,
`Frame Relays, etc.
`The World Wide Web (the "Web") has come to the
`10 forefront in the current era of the Internet/intranet and
`networks have become an integral part of day to day work.
`Modem speeds double every year and 100 Mbit/sec Local
`Area Networks have arrived. The Web is now a well(cid:173)
`accepted medium for publishing information, in the form of
`15 text and graphics (including sound and video). Web pro(cid:173)
`gramming languages such as Java, JavaScript, and CGI have
`now extended the Web to applications. This is fine for new
`applications but existing applications also need a route into
`this world.
`Existing applications have either had a character-based or
`windows-based user interface. Now such applications need
`a web user interface. The web user interface provides a
`presentation layer to the user of the application. It must
`provide an input/output method for the user to interact with
`25 the application. There are a number of ways to do this
`including: (1) HTML (HyperText Markup Language)
`replacement of the current user interface; (2) Non-Java
`plug-ins; and (3) Java-based emulation. The first solution
`involves rewriting the application. The second involves
`30 installing more software on the clients leading to "fat
`clients". The third is preferred.
`A large number of vendors offer a character or graphical
`emulation package that runs on desktop clients such as
`Windows, UNIX, etc. These emulators could be rewritten in
`Java and such Java emulator will run on just about any
`client. However, this approach leads to fat Java clients. For
`performance reasons, users will not want to wait for large
`Java applets to download. These Java applets will grow in
`size as users demand more and more functionality. Storing
`these Java applets locally solves the performance problem
`but leads to fat clients. If state information is stored on the
`client leading each client to have its own particular configu(cid:173)
`ration parameters, the problem of fat clients is further
`exacerbated and each client is being managed individually
`rather than from a central place on the server.
`Web browsers have an API (Application Programmers
`Interface) enabling software developers to provide helper
`applications that allow users to run applications or view
`unsupported document types on their client platform. These
`are termed "browser plug-ins". They are both platform-
`specific and browser-specific. For example, for two plat(cid:173)
`forms (Windows and UNIX) and two browser types
`(Netscape and Microsoft), four different implementations of
`the plug-in would be needed. This type of solution is not
`cross platform and the majority of these plug-ins are pro-
`prietary (e.g., Microsoft ActiveX) locking users into vendor
`specific solutions.
`Once the web display of an application is possible, the
`60 next step is to make it available to all users. A number of
`methods that could be used include: (1) local installation; (2)
`push technology; (3) on-demand access. Local installation
`involves an administrator installing the application or con(cid:173)
`nectivity software on every single client. This is disadvan-
`65 tageous in that it makes the clients more difficult and costly
`to manage and leads to fat clients. Push technology involves
`storing all the files and data associated with users and
`
`35
`
`1. Field of the Invention
`The present invention relates to networked data process(cid:173)
`ing environments using a client/server architecture, and, in
`particular, to client-server systems where there exist one or
`more clients of varying capability connected via network
`connections of varying bandwidth and latentcy to one or
`more servers providing application services or database
`services to the connected clients.
`2. Background Information
`Until the 1980s the computer network typically was used 40
`as a means of connecting to a large mainframe environment
`using dedicated hardware terminals and proprietary proto(cid:173)
`cols. Next UNIX servers grew in usage and with it came
`standardization of the networking protocols, in particular
`TCP/IP (Transmission Control Protocol/Internet Protocol). 45
`Simultaneously, there was a shift in the computing paradigm
`towards client/server architectures. This allowed the pro(cid:173)
`cessing power to be distributed over the network and not be
`limited to servers which could not scale to meet the growing
`number of users and their increasing demands. This lead to 50
`the need for clients to become more intelligent and powerful.
`Significant desktop clients came into use: Microsoft Win(cid:173)
`dows. Each iteration of this operating system brought about
`more functionality requiring more powerful desktop clients.
`More and more software had to be installed on these clients 55
`leading to what is termed "fat clients" and each client
`required individual configuration. People began to find that
`the amount of time and money required to maintain these
`powerful clients was increasing.
`High availability networks together with hardware and
`software needed to support such networks have become the
`norm. In these environments there is not a homogeneous
`structure of one type of server and one type of client, but a
`variety of such devices. Within a network there is a wide
`variety or servers and clients. Upgrades and new applica(cid:173)
`tions for this diverse mix of clients usually requires that each
`client be individually upgraded. Also each user has specific
`
`

`
`6,104,392
`
`3
`applications on a server and transmitting them out via virtual
`channels on a network to clients. Where all storage is on the
`sever, users experience poor performance in waiting for
`applets and applications to execute, or downloads are cum(cid:173)
`bersome and in some cases unusable. Local storage of
`applications and state information is used to improve per(cid:173)
`formance. This approach starts off well by using a central
`server but when applications and any associated state are
`stored on the client, the fat client problem arises. With
`on-demand access as used in the present invention, user
`state, applications, connectivity software and the associated
`configuration data are stored on a server. Applets are down(cid:173)
`loaded on demand when the clients request an action, such
`as start up an application. All state information is kept on the
`server and can then be managed centrally rather than indi(cid:173)
`vidually on each client. Keeping state information on the
`server also makes the client resilient. If the client connection
`is lost or the client itself is replaced, nothing is lost and no
`replication is needed.
`Next the applications and data must be made available to
`selected users in a secure manner. For manageability, this is
`done centrally on a server and made available by the most
`common medium to all users, the Web. But this raises more
`questions:
`What do web pages on that server have to contain?
`What editor has to be used?
`How do you make it available to selected users or groups
`of users?
`Are there different web pages for different types of users?
`Where does the user profile and application configuration
`reside?
`Do users authenticate themselves every time they want to
`run applications?
`How is the authentication done?
`What if the user is already authenticated on the server and
`does not want to do again and again for each applica(cid:173)
`tion?
`What if all of this information is already available and
`duplication is not desired?
`As the above list shows, providing a display mechanism via
`Java emulation is only a partial solution to web-based
`delivery of applications.
`To achieve optimal performance on all networks is diffi(cid:173)
`cult. Protocols are designed with specific functions in mind,
`e.g., inter-process communication, graphics rendering, etc.
`Protocols are rarely designed with the goal of providing
`uniform performance over complex network routes that have
`different permutations of bandwidths. To choose the right
`protocol a number of assumptions could be made. For a high
`bandwidth network, such as a fast LAN with low latency, the
`X protocol works well but is unusable over a slow modem
`link. For a low bandwidth network, such as a slow WAN or
`modem connection, compression can be used to optimize
`performance. The ICA protocol of Citrix Systems, Inc.
`works well over a slow modem connection but is inefficient
`on a fast LAN connection.
`It would be advantageous to be able to deliver upgrades
`to existing applications or roll out new applications to
`diverse clients; to be able to centralize the administration of
`clients and their applications; to have a system that is able
`to adapt itself to the network environment it works in; and 60
`to provide optimal performance for diverse clients that are
`connected to the network via routing connections of differ(cid:173)
`ing bandwidth and performance.
`
`10
`
`4
`a user via a client device having a display engine operating
`thereon. The method permits the efficient operation of the
`application without overloading the connection to the client
`device. The method transmits to and displays on the display
`5 device of the client device, display requests of the requested
`application service which are not supported by the client
`device. It does this by using two major processes, a display
`engine and a protocol engine. The display engine is down(cid:173)
`loaded from the server and executes on the client device a
`display engine. Next, the protocol engine is initializing with
`parameters of the client device comprising display opera(cid:173)
`tions supported by the client device, the relative cost of each
`supported operation and a local performance factor and
`parameters of the connection from the server to the display
`engine comprising bandwidth and latency. The protocol
`15 engine maintains a first queue for retaining pending display
`requests and a second queue for retaining transmitted dis(cid:173)
`play requests of the requested application service for display
`on the client device. Each request has a corresponding
`relative cost and request time determined by the relative cost
`20 and the local performance factor. The protocol engine also
`maintains a total request time for all requests in both queues
`and maintains a total network time for all requests in the
`second queue.
`While the total request time is less than a predetermined
`25 first value, the protocol engine accepts new pending requests
`from the application service that are to be displayed on the
`client device. The protocol engine executes the new pending
`display request to create an image to be displayed on the
`client device, saves the resulting image to memory and
`30 determines for the image its relative cost and its correspond(cid:173)
`ing request time based the local performance factor received
`from the display engine. The protocol engine also converts
`the new pending display request from the application service
`into a sequence of converted requests that are supported by
`the client device, places the sequence of converted requests
`35 in the first queue, determines for each converted display
`request in the sequence its relative cost and its correspond(cid:173)
`ing request time based on the local performance factor, and
`increments the total request time by the request time of each
`added request. Further while the total network time is less
`40 than a predetermined second value optimizing the first queue
`using a merge optimization occurs when the request times of
`the pending requests in the first queue exceed a predeter(cid:173)
`mined third value. The total request time is updated based on
`the results of the merge optimization. Next a pending request
`45 is read from the first queue and labeled with a first sequence
`identifier. Each read request is then encoded for transmission
`to the display engine over a network connection. A copy of
`the optimized request is placed into the second queue and the
`total network time is incremented by the request time for the
`50 newly added request. The encoded display request is trans(cid:173)
`mitted to the display engine. The display engine unencodes
`the received converted display request and displays it on the
`client device. Next it generates a second sequence identifier
`corresponding to first sequence identifier of the displayed
`55 request; and periodically transmits to the protocol engine the
`second sequence identifier of the last received display
`request displayed on the client device.
`Upon receipt of the second sequence identifier, the pro(cid:173)
`tocol engine further comprises the steps of:
`deleting from the second queue the display request whose
`first sequence identifier is the same as the second
`sequence identifier and all pending displayed requests
`in the second queue having first sequence identifiers
`that are prior to such second sequence identifier; and
`decrementing from the total request time and from the
`total network time the request time values of each of the
`deleted display requests.
`
`SUMMARY OF THE INVENTION
`The inventive method is used in a client server network
`that provides at least one application service for selection by
`
`65
`
`

`
`6,104,392
`
`5
`In the inventive process various optimization techniques
`can be used based on a performance factor that is determined
`for the client device and various encoding techniques can be
`implemented depending on the bandwidth and latency of the
`network connection to the client device. Preferably, the 5
`process is programmed using a machine independent pro(cid:173)
`gramming language.
`
`BRIEF DESCRIPTION OF THE SEVERAL
`VIEWS OF THE DRAWINGS
`
`For a better understanding of the invention reference may
`be made to the preferred embodiments of the invention
`shown in the accompanying drawings where:
`FIG. 1 illustrates a Universal Application Server (the
`"UAP") system comprised of a client/server network show(cid:173)
`ing the interconnection of the UAP server to other applica(cid:173)
`tions and database servers and to a diverse set of clients;
`FIG. 2 is an illustration of the Adaptive Internet Protocol
`(AIP) Link as implemented in the UAP system;
`FIG. 3 shows the processes operating in the display
`engine and protocol engine components of the present
`invention;
`FIG. 4 is a more detailed data flow diagram of the AIP link
`of the present invention;
`FIG. 5 is a table of sample AIP requests; and
`FIG. 6 presents a table of AIP request translations and a
`table of sample relative costs for performing an AIP request.
`
`6
`82F. The UNIX X window server 82A and the Windows NT
`server 82B interface to the second tier 40 via X Windows
`interface 60. The UNIX and IBM character-based applica-
`tion servers 82C interface via appropriate terminal emulators
`62. The web server 64 provides the interface to the Internet
`82E while the directory services server 82D uses the LDAP
`interface 66. Although all of the application servers are
`shown in FIG. 1 as being in a single tier, it should be realized
`that the application servers can also function as clients to
`10 other servers not shown and that the requested application
`may reside in a server located elsewhere in the network.
`Also shown are User Session Manager engine 70 which
`controls active sessions between the client devices 14 and
`the application servers 82 and the Administration and Man-
`15 agement manager engine 72 which controls the operation
`and administration of UAP server 50 and which is in
`communication with the administrative computer 20 oper(cid:173)
`ated by a system administrator.
`Client connections and requests, 30, are routed to the
`20 appropriate interfaces on UAP server 50 which in turn
`processes them using one of more of the UAP engines
`described below and obtains the requested service or data
`from the appropriate application server 82. UAP server 50
`then returns to the client devices 14 display requests from
`25 the requested application and other data. UAP server 50
`resides on a host or server on the network that has a web
`server running on it. It can be viewed as a black box sitting
`somewhere on the network that enables any client to access
`any service by providing the intelligence needed to do this.
`A variety of naming standards and methods are used to
`access resources on the network. Computers on the Internet
`use conventions such as Domain Name Service (DNS) or
`Windows Internet Naming Service (WINS). File naming
`conventions are tied to operating systems of which there are
`35 many. For example, Microsoft operating systems use the
`Universal Naming Convention (UNC). These resources are
`disparate and different entry points and methods are needed
`to access them. The UAP server provides an integration
`point for a wide variety of naming standards by federating
`40 the name spaces. It provides a single point of entry to access
`any network resource. The X/Open Federated Naming
`(XFN) based scheme is the preferred naming standard to
`permit such integration amongst these variety of naming
`services and standards.
`Large and complex information about network resources
`is usually kept by directory servers, for example, Novell®
`NDS™, Microsoft Active Directory, Netscape Directory
`Server™. UAP server 50 does not provide a complete
`replacement or duplication of these services. UAP server 50
`provides a thin layer that interfaces into these services using
`LDAP (Lightweight Directory Access Protocol). LDAP is a
`current de facto industry standard interface to directory
`services. By doing this UAP server 50 avoids duplication of
`information and functionality which may already be present
`55 on the network. It would be an unnecessary and time(cid:173)
`consuming process to replicate this information. For
`example, if a thousand users are already set up, the use of the
`LDAP layer allows use of this information by UAP server 50
`and administrative engine 72, rather than making adminis(cid:173)
`trators recreate it and double the maintenance load.
`As illustrated in FIG. 2, UAP server 250 contains the
`following processes: administration engine 272; status man(cid:173)
`ager engine 274, protocol engines, 276A-276C, display
`engines 278A-278C; web server 264 and webtop storage
`65 268 for the storage of user webtops; data store 273 contain(cid:173)
`ing various user and system data such as the LDAP protocol,
`user passwords, user application objects, startup engine, and
`
`30
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`Overview of a Universal Application Server System
`As used in this application the term "engine" is used to
`refer to a process, method or series of related processes or
`methods for performing certain actions. For example the
`session engine is a process that is used to control a current
`session between the server and a client device. Also the same
`or similar item occurring in more than one figure will carry
`the same or similar numeric designation.
`As shown in FIG. 1, the network 10 is comprised of three
`tiers used to illustrate the connections of the various inven(cid:173)
`tive processes and routing of data information among the
`various processes and components comprising the network.
`The first tier 12 contains a variety of diverse client devices,
`generally indicated at 14, having different interfaces, such as 45
`PC 14A, UNIX computer 14B, Network Computer 14C, all
`illustrated as having a Java Virtual machine interface 16 to
`the second tier 40, or a thin client 14D shown having a
`browser interface 18. The inventive processes are also
`useable in a standard Microsoft Windows environment that 50
`use interfaces such as Win16 and Win32. In addition, an
`administrative computer 20, illustrated as a network
`computer, is also grouped in first tier 12 and is in commu(cid:173)
`nication with processes running on second tier 40.
`The second tier 40 comprises UAP server 50 having
`various engines or processes executing thereon together with
`various interfaces to first tier 12 and to third tier 80. The
`interfaces to first tier 12 include X windows interface 52,
`character based interface 54, Java interface 56, and HTML
`interface 58. The interfaces to third tier 80 include an X 60
`Windows interface 60, terminal emulators 62, web server
`64, and lightweight directory access protocol (LDAP) inter(cid:173)
`face 66. The third tier 80 includes the various application
`servers, generally indicated at 82, including UNIX X Win(cid:173)
`dows server 82A, Windows NT server 82B, UNIX and IBM
`character-based application servers 82C, directory services
`servers 82D, the Internet 82E and various data base servers
`
`

`
`6,104,392
`
`10
`
`25
`
`7
`other data related to the operation of UAP server 50, data
`store engine 271 and one or more session managers 270,
`which can be configured to permit suspendable and resum(cid:173)
`able sessions. Login port 251, reconnect port 253, a plurality
`of session ports 255 are provided for communication with 5
`client devices. Display engines, generally designated 278,
`are stored on UAP server 250 and are downloaded to client
`device 214 when needed. Client device 214 is a computer
`system that has a display and input devices such as a
`keyboard, mouse, touchpad, etc., as is known in the art.
`Shown in the third tier 280 are three application servers,
`generally designated 282, X Windows server 282A, Win(cid:173)
`dows NT server 282B, and character-based server 282C.
`UAP server 250 provides administrative engine 272. Only
`authorized administrative users have the ability to run this
`process. The main functions of the administrative engine 15
`272 are:
`Publishing applications and documents to users
`Organizing user profiles (what each user is allowed to
`access)
`Viewing and changing the contents of the organizational
`hierarchy
`Monitoring and controlling sessions, including viewing
`which users are logged on and what applications are
`running, and stopping applications
`Configuring the UAP server settings such as logging and
`diagnostic specification, authentication mechanisms
`and file locations
`Sitting at the heart of UAP server 250 is a suite of server
`engines or processes that coordinate all functions. These are
`status manager engine 274, datastorc engine 271, session
`manager engine 270, protocol engines, generally designated
`276, and the display engines 278. These engines cooperate
`to provide the central point of access to the client devices
`and handle the following:
`Security management
`Retrieval and storage of state associated with users and
`applications
`Invocation of applications and their supporting display
`mechanisms
`Sessi