Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
1999-03-31
2002-03-26
Nguyen, Cao H. (Department: 2173)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C709S207000
Reexamination Certificate
active
06362836
ABSTRACT:
STATEMENT REGARDING FEDERALLY FUNDED RESEARCH
Not Applicable.
REFERENCE TO A MICROFICHE INDEX
Not Applicable.
COPYRIGHT NOTICE
Copyright 1999 The Santa Cruz Operation, Inc. A portion of the disclosure of this patent document contains materials that 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
1. Field of the Invention
The present invention relates to networked data processing 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 program services or database services to the connected clients.
2. Background Information
Until the 1980s the computer network typically was used as a means of connecting to a large mainframe environment using dedicated hardware terminals and proprietary protocols. Next UNIX servers grew in usage and with it came standardization of the networking protocols, in particular TCP/IP (Transmission Control Protocol/Internet Protocol). Simultaneously, there was a shift in the computing paradigm towards client/server architectures. This allowed the processing 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 the need for clients to become more intelligent and powerful. Significant desktop clients came into use: Microsoft Windows. 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 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 applications for this diverse mix of clients usually require that each client be individually upgraded. Also each user has specific needs on the desktop client: configuration, security, access control, mobility. The information services department provides this by administering each client separately. If remote offices are involved, costs to do this increase significantly. 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 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-accepted medium for publishing information, in the form of text and graphics (including sound and video). Web programming 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 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 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 configuration 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 platforms (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 proprietary (e.g., Microsoft ActiveX) locking users into vendor specific solutions.
Once the web display of an application is possible, the 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 connectivity software on every single client. This is disadvantageous 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 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 cumbersome and in some cases unusable. Local storage of applications and state information is used to improve performanc. 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 downloaded 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 individually 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 application&
Anderson Raymond
Binns Roger David
Burgess Karl Richard
Cartwright Peter Charles
Pullan John Marcus
Fulbright & Jaworski
Nguyen Cao H.
The Santa Cruz Operation, Inc.
LandOfFree
Universal application server for providing applications on a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Universal application server for providing applications on a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Universal application server for providing applications on a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2818214