throbber
United States Patent [19J
`Anthias
`
`I IIIII IIIIIIII Ill lllll lllll lllll lllll lllll lllll lllll lllll 111111111111111111
`US005920311A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,920,311
`Jul. 6, 1999
`
`[54] DISTRIBUTED CLIENT/SERVER WINDOW
`PRESENTATION SYSTEM
`
`[75]
`
`Inventor: Taf Anthias, Ramsey, United Kingdom
`
`[73] Assignee: International Business Machines
`Corporation, Armonk, N.Y.
`
`[21] Appl. No.: 08/163,416
`
`[22] Filed:
`
`Dec. 6, 1993
`
`[30]
`
`Foreign Application Priority Data
`
`Dec. 22, 1992
`
`[GB]
`
`United Kingdom ................... 9226706
`
`Int. Cl.6
`...................................................... G06F 13/00
`[51]
`[52] U.S. Cl. ............................................. 345/329; 345/340
`[58] Field of Search ..................................... 395/155-161,
`395/153, 200.31, 200.33, 200.47; 345/119,
`120,329,335,339,340,342,343
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`4,642,790
`4,651,146
`4,665,501
`
`....................... 345/341
`2/1987 Minshull et al.
`3/1987 Lucash et al. .......................... 345/340
`5 /1987 Sal din et al. ... ... ... ... ... .... ... ... ... 395 /828
`
`4,782,463
`4,845,644
`4,954,966
`5,175,813
`5,461,716
`
`11/1988 Sanders et al. ... ... .... ... ... ... ... ... 395 /701
`7/1989 Anthias et al.
`......................... 345/343
`9/1990 Mooney et al.
`........................ 345/341
`12/1992 Golding et al. ......................... 345/340
`10/1995 Eagen et al. ............................ 345/340
`
`Primary Examiner-Matthew M. Kim
`Assistant Examiner----Crescelle N. dela Torre
`Attorney, Agent, or Firm-Douglas H. Lefeve; Thomas E.
`Tyson; J. B. Kraft
`
`[57]
`
`ABSTRACT
`
`This invention addresses the management of window geom(cid:173)
`etry ( or layout) in a distributed data processing system. In
`this invention, a client server model includes an application
`executing on a client system with graphics being drawn on
`the server system for the end user. Each client application
`interacts with the user by defining client windows into which
`are placed graphical data and where input data may be
`entered by the user. The application software together with
`the graphics software is provided in the client processor. The
`server processor includes the ability to display data to the
`end user. The application data for display, in the form of a
`window, includes a special designated area within the win(cid:173)
`dow to provide user access to the application.
`
`2 Claims, 2 Drawing Sheets
`
`SHARED
`DATA
`
`LAN DATA
`SERVER
`
`5
`
`10a
`
`20a
`
`10b
`
`CLIENT
`APPLICATION
`MOOE$
`
`DISPLAY SERVER NODES
`
`Ralph Lauren Corp., Exhibit 1005 Page 1
`
`

`

`U.S. Patent
`
`Jul. 6, 1999
`
`Sheet 1 of 2
`
`5,920,311
`
`s
`
`SHARED
`DATA
`
`LAN DATA
`SERVER
`
`100
`
`10b
`
`CLIENT
`APPLICATION
`-+-~"'"*"~~ MOOES
`
`DISPLAY SERVER NODES
`
`Fl G. 1
`
`DISPLAY SERVER
`30b
`
`300
`
`• t
`F1•Hel
`4
`
`D
`
`Title • •
`t
`CJ
`I
`0
`
`FMielp D I
`Do +
`
`20b
`
`OTHER
`CONTROLS--
`
`Ill
`
`•
`
`t
`
`ENTRY FIELD
`
`TOP LEVEL
`WINDOWS
`
`FIG. 2
`
`Ralph Lauren Corp., Exhibit 1005 Page 2
`
`

`

`U.S. Patent
`
`Jul. 6, 1999
`
`Sheet 2 of 2
`
`5,920,311
`
`CLIENT NOOE
`
`APPLICATION
`A
`
`APPLICATION
`B
`
`APPLICATION
`C
`
`so -r--
`
`OPM
`ROUTER
`
`60 _.,...-
`
`SERVER
`55 _...-r-- fNPUT
`QUEUE
`
`10./ TLPB
`
`SERVER NOOE
`
`GRAPHICS
`ENGINE
`
`~-80
`
`,r
`
`FIG. 3
`
`Ralph Lauren Corp., Exhibit 1005 Page 3
`
`

`

`5,920,311
`
`1
`DISTRIBUTED CLIENT/SERVER WINDOW
`PRESENTATION SYSTEM
`
`2
`overheads in the server, as well as unnecessary network
`traffic to create and modify these application windows.
`
`DESCRIPTION
`
`SUMMARY OF IBE INVENTION
`
`5
`
`Viewed from one aspect, the present invention provides a
`data processing system comprising: a remote processor and
`associated memory coupled to a local processor and asso(cid:173)
`ciated memory; the remote processor including means for
`executing a plurality of application programs and sending
`10 window display data generated by the application programs
`to the local processor, the local processor including means
`for receiving the window display data and drawing the data
`as respective application windows, each containing one or
`more sub area windows within their perimeter, and where the
`15 application programs designate one or more of the subarea
`windows as an action field through which a user may access
`the respective application program, and is characterized in
`that display data common to both an application window and
`a corresponding action field is stored in the memory asso-
`20 ciated with the local processor and remaining display data is
`stored in the memory associated with the remote processor.
`In accordance with the present invention, much of the
`information for a specific window can be managed entirely
`within the client presentation layer (for example, style
`25 information, callback addresses, etc.). The invention recog(cid:173)
`nizes that not all windows generated in a client application
`program need to be externalized to the server. Only those for
`which the server needs to perform some different processing
`need to be externalized. An advantage of this approach is
`30 that it leads to a reduction in the network traffic necessary to
`create and modify application windows. A further advantage
`is the reduction in storage requirements and processing
`overheads in the server system.
`
`1. Technical Field
`The present invention relates to distributed data process(cid:173)
`ing systems. More particularly, this invention relates to
`management of the window geometry (or layout) in a
`distributed client/server presentation system.
`2. Background of the Invention
`In a distributed data processing system, a computer user
`typically interacts with a local computer terminal which is
`known as the server system. The server system is connected
`functionally, by means of a communications network, to a
`remote data processing system which is known as the client
`system. The server system is not necessarily situated any
`great distance from the client system. An example of such a
`distributed data processing system is a PC workstation and
`host processor in a local area network where the client
`processing system and the workstation server are in the same
`building or possibly even the same office. A server system
`may also be connected to more than one client system.
`In known distributed data processing systems in which an
`application is operating on the client system and correspond(cid:173)
`ing graphics data is being drawn on the server system (where
`the end user is), the client application interacts with the user
`by defining client windows into which is placed graphical
`data and from which input entered by the user is received.
`An example of such input is mouse movement events when
`the mouse-pointer/cursor is in the window. The graphics
`input and output capability is provided by the server pre(cid:173)
`sentation system. The presentation system of a computer
`system is the layer of the architecture that provides the
`functions that may be selected by the application layer such 35
`as exchange, display and control of structured data. The
`server provides the support in the end-user node to process
`drawing and other requests for output and to direct the
`generated input to the correct place. The server may be
`interfacing with a number of client systems as the user may 40
`be executing applications which reside on a number of
`connected client nodes. The server needs to have sufficient
`understanding of the way the output area of the screen is
`used to allow clients to receive input and coordinate their
`drawing on to the appropriate local server terminal.
`When the user moves the mouse (or cursor), a mouse (or
`cursor) event is generated. As the server may be used by a
`number of client nodes, it is not possible to route an (x, y)
`value to a client windowing component unless the server can 50
`identify that this client node owns the relevant part of the
`display. Clearly, the server needs to have some understand(cid:173)
`ing of the window geometry. For example, it needs to know
`to which client system to send a specific mouse-generated
`event. Usually this would be the client system which owned 55
`that part of the screen where the pointer/cursor is.
`There are other factors which require the server to have
`some understanding of the display window geometry. For
`example, in the case of overlapping windows, when a
`window is deleted by a client, other clients need to be told 60
`when and in which regions they need to repaint the data
`uncovered as a result of the deletion.
`In known presentation systems such as X-Windows,
`which is a presentation system of the UNIX (registered
`trademark of Unix Systems Laboratories, Inc.) operating
`system software, the entire window geometry is stored in the
`server. This leads to unnecessary storage and processing
`
`BRIEF DESCRIPTION OF THE DRAWING
`
`In order that the invention may be fully understood, a
`preferred embodiment thereof will now be described, by
`way of example only, with reference to the accompanying
`drawings in which:
`FIG. 1 shows a schematic diagram of a distributed data
`processing system;
`FIG. 2 shows an example of the screen display of a server
`node showing windows and corresponding device areas; and
`FIG. 3 shows a schematic diagram of the structure of a
`distributed data processing system.
`
`45
`
`BEST MODE FOR CARRYING OUT THE
`INVENTION
`FIG. 1 shows an example of a distributed data processing
`system. The client nodes are indicated at 10a and 10b and
`the server nodes are indicated at 20a, 20b, 20c and 20d. Each
`of the client nodes are running three applications respec(cid:173)
`tively. It can be seen that server node 20b is accessing an
`application on each of the client nodes. The resulting display
`from application C is displayed in window 30a on the
`display server node 20b and the resulting display of appli(cid:173)
`cation D is displayed in 30b. The LAN server 5 is used by
`each client node to access shared data.
`The applications (A, B, C, D, E, F) define client appli-
`cation windows (e.g., 30a, 30b). The client presentation
`system only externalizes to the server the minimum needed
`for it to carry out its responsibilities. The client presentation
`system holds all other data required for drawing the main
`65 application windows 30a, 30b.
`The server maintains the window geometry in a list of
`device areas. This terminology is used to distinguish them
`
`Ralph Lauren Corp., Exhibit 1005 Page 4
`
`

`

`3
`from windows (such as 30a and 30b) as seen by the
`applications. A typical server screen display showing appli(cid:173)
`cation windows and corresponding device areas is shown in
`FIG. 2. A device area is a subarea window displayed within
`an application window and which is designated by the
`application program as an action field through which a user
`may write to the application.
`Compared to an application window, a device area is a
`light-weight structure in that only a minimal amount of
`attribute data is required for it to be drawn on the screen. It
`is similar to a window but contains only a portion of the
`window information. Device areas are maintained in a
`priority ordered list, not a hierarchy, in the server. In
`comparison with the prior art, the server overheads in both
`processing time and storage requirements are reduced as the
`complete set of application window data is not stored at the
`server. The order of the device areas in the ordered list
`changes when the priority of a device area changes, e.g.,
`when overlapping windows are redrawn in a different order
`by the client system so that a window which previously
`overlapped another window becomes itself overlapped.
`Preferably, device areas are not used for drawing into by
`applications running on the client system. The separation of
`input-related and output-related window geometry allows
`many optimizations to take place. The server only needs the
`device areas once the data is drawn to the display.
`With the approach described herein, it can be seen that
`both the number of windowing areas and the contents of a
`windowing area are reduced.
`A pointer/cursor can be associated with a device area. The
`server responds to mouse movement by redrawing the 30
`associated pointer when the mouse x, y value falls within the
`device area.
`Device areas are allocated for all top-level windows so as
`to allow routing to the appropriate client node when the
`input is entered into that part of the display by the user. 35
`Allocating device areas for each control in a dialog is
`unnecessary if there is no difference in what the server will
`do as a result. For example, input would go to the same node
`as the parent top-level window, the default system pointer
`may be used for all controls in the dialog and repainting can 40
`be handled by the client system driving the appropriate
`window painting procedures.
`Device areas are shown in FIG. 2 at 40a and 40b. The
`device area structure contains the following data:
`x, y, ex, cy (position and size in screen coordinates)
`input interest settings (e.g., mouse move required)
`pointer handle for device area
`handle of client connection
`handle of save bits data (backing store).
`FIG. 3 shows schematically the structure of the client and
`server systems of a distributed data processing system. In
`this diagram, it is assumed that the server is remote to the
`client system. The client system 10a contains the entire
`application (A, B. C). The application message queue 50 55
`resides in the client and is updated by the client presentation
`system from input received via the server input queue 55 and
`from messages generated on client nodes. The client system
`interfaces (via the presentation system router) with the
`server system. The data sent between client and server 60
`presentation systems is known as the presentation system
`protocol. The transport mechanism is the Transport Layer
`Protocol Boundary (TLPB) 70.
`The majority of protocol requests are handled by the
`graphics engine component 80 of the server, which inter- 65
`faces with the display device driver to output graphics data
`to the display.
`
`45
`
`50
`
`5,920,311
`
`5
`
`4
`The steps taken in the creation of a device area in a
`distributed data processing system are shown in Table 2.
`First of all, the main window, such as 30a of FIG. 2, is
`created in the client system. At this stage, the data required
`to draw the main window on the screen of the server is stored
`in the client system. This data includes such attributes as
`window size, position, color, fonts, addresses, etc. A device
`area is then defined in the client presentation system. This
`10 device area is associated with the frame of the main window.
`The information necessary to define a device area is much
`less than that required to define a main window. In a
`preferred embodiment of the present invention, five data
`fields (shown in Table 1) are necessary to define a device
`15 area, whereas about 200 are required to define a main
`window. Next, the client presentation system associates a
`particular cursor type with the device area. Preferably the
`cursor type which will appear in the device area when it is
`20 displayed on the screen of the server node is different from
`the cursor type which will appear in other parts of the
`window associated with that device area. The cursor will
`change shape (or color or flashing frequency) as it passes
`from the background window areas to the device area. One
`25 reason for this cursor change is to indicate to a user that the
`cursor has entered an entry field of the window. More device
`areas are then created by the client presentation system as
`required.
`
`TABLE 1
`
`DEVICE AREA CREATION IN CLIENT
`
`CLIENT
`APPLICATION
`SYSTEM
`
`CLIENT
`PRESENTATION
`SYSTEM
`
`SERVER
`PRESENTATION
`SYSTEM
`
`create main
`window
`(window data)
`
`create dialogue
`sub windows
`(buttons, list
`boxes, input
`fields)
`
`( only a subset of
`window info is
`needed for the
`device area)
`
`define device
`area for frame
`associate standard
`cursor with device
`area
`
`scan subwindows for
`variations from main
`window
`For text input fields
`requiring special
`cursor define device
`area to request server
`to change cursor -
`similarly for other
`windows requiring
`variation
`send device areas to
`server
`
`Draw subwindows into
`main window
`
`process user
`input ac-
`cording to
`device area
`geometry
`
`Ralph Lauren Corp., Exhibit 1005 Page 5
`
`

`

`5,920,311
`
`5
`
`TABLE 2
`
`DEVICE AREA CREATION IN CLIENT
`
`CLIENT
`APPLICATION
`SYSTEM
`
`CLIENT
`PRESENTATION
`SYSTEM
`
`SERVER
`PRESENTATION
`SYSTEM
`
`(Subwindows not
`externalized to
`server as device
`areas appear like
`pure graphics)
`
`For input device
`(e.g., mouse
`movement) examine
`device area list
`to find device
`area for new x, y
`position. Change
`to new cursor if
`necessary. For
`input keys,
`generate host in-
`put for client
`system owning
`device areas.
`
`5
`
`10
`
`15
`
`20
`
`Dialogue windows are created in the client system. These
`subwindows are scanned for variations by the presentation
`system of the client system. The client presentation system
`then defines a device screen to request the server to change
`the cursor for text input fields which require a special cursor.
`If, after a check, there are no more variations from the main
`window, the data representing the device areas is sent to the
`server by the client presentation system. The remaining data
`representing the main window is retained by the client 30
`system. The subwindows are drawn into the main window.
`Any user input is then processed by the server presentation
`system.
`
`25
`
`6
`
`We claim:
`1. A data processing system comprising:
`a display terminal,
`a local processor connected to said display terminal and
`connected to a local processor memory,
`a remote processor connected to said local processor and
`connected to a remote processor memory,
`said remote processor including means for executing a
`plurality of application programs and means for send(cid:173)
`ing window display data generated by said application
`programs to said local processor,
`said local processor including means for receiving said
`window display data and drawing respective applica(cid:173)
`tion windows, each of said application windows con(cid:173)
`taining at least one subarea window within its
`perimeter,
`said application programs designating at least one of said
`subarea windows as an action field through which a
`user may access a respective application program,
`means for storing said respective application program
`window display data common to both one of said
`application windows and said corresponding action
`field in the local processor memory, and
`means for storing window display data defining a remain(cid:173)
`ing portion of said one of said application windows
`outside said subarea designating said action field, in the
`remote processor memory.
`2. A data processing system as claimed in claim 1 wherein
`user input data for an application program is entered in one
`of the action fields and is sent from the local processor to the
`remote processor for execution.
`
`* * * * *
`
`Ralph Lauren Corp., Exhibit 1005 Page 6
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket