Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
2000-07-18
2004-05-18
Nguyen, Cao (Kevin) (Department: 2173)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C345S215000
Reexamination Certificate
active
06738077
ABSTRACT:
BACKGROUND
1. Field of the Invention
The present invention relates to database software applications. More specifically, the present invention relates to the interworking of desktop applications and databases.
2. Description of Related Art
One common practice in the field of database systems deployment is to build client applications after the database is laid out and its schema or model has been defined.
Database systems primarily consist of three tiers:
Tier 1 (referred to hereafter as “database”)—one or more data sources (usually relational databases, but also directory services like LDAP (Lightweight Directory Access Protocol) or object-oriented databases;
Tier 2 (referred to hereafter as “application server” or “server”)—one or more server applications/systems connecting to the database and providing data to Tier 3; and
Tier 3 (referred to as hereafter as “client application” or “client”)—one or more programs providing a front-end to the data provided by the application server.
Object-oriented application servers present the data fetched from the data sources as objects in a high level programming language like Java. For relational database systems, servers usually have to “map” the data from the data sources into objects (transform data sources storing data in tables and fields relationally into an object framework). In the case of object-oriented databases in tier 1 such mapping is not necessary.
Application servers use a so-called “database model” or “model” to define how the data objects they work with map to the underlying data source. Models consist of “entities” which are descriptions of the data objects. Every entity describes one type of data object. Entities are defined with the help of “attributes” and “relationships” (both attributes and relationships are also referred to as “properties”, so every attribute and every relationship is a property). An “attribute” is a persistent atomic piece of information assigned to a data object (for example a customer's name or an order number). Every entity has a “primary key” which is used to identify objects uniquely (usually the primary key is a subset of the attributes of the entity). Relationships define how objects behave and are conditioned in relation to one another (for example, an order can be assigned to exactly one customer (so-called “to-one relationship”) and a customer can have multiple orders (so-called “to-many relationship”)).
Entities in the model can map to one table in the database or to multiple ones (for example, in the case of object inheritance where different variations of an object class are mapped to different tables in the database). In relational databases, relationships are defined with the help of attributes (objects relate to each other if values of specific attributes are identical) which can map to one or multiple fields in the database. The application server can maintain attributes used for primary keys and relationships (referred to as “foreign keys”) separately from the data object used to present the data from the data source, so that primary keys and foreign keys do not appear as attributes of the data object itself. The application server then handles filling in the values for these primary and foreign keys when communicating with the database.
On a system level, referring again to the three tiers, due to the inherent independence of these tiers, each client or server is typically programmed/configured to transact with the data store in an independent fashion. In the case of a client, a user interface (UI) that allows users to interact with the data store is usually built as a desktop window application displayed on the client. The UI application is built manually and is based upon a human interpretation of the database model/framework. Based on the model, the human designer would design windows and views that would present the various entities and other data objects in a friendly, easy-to-manipulate manner. Based upon this design, program code for the UI was written/generated and then the application executable compiled. The application is then executed on the client machine and then connects with the server which links the data store together with the client. The client UI is then able to fetch objects from the server and present them to the user for viewing, updating and modification as desired. Once the client UI application is developed, it can be duplicated and distributed to clients having a compatible instruction-set and/or operating system platform. However, where UI applications are needed for clients incompatible with that of the developed application, a new application, and perhaps new design, needs to be programmed, compiled and executed.
With the advent of the Java programming environment, executables could be programmed on one machine an then run on any other platform, whether compatible or not. The primary distribution of Java (a product of Sun Microsystems) applications, such as Java “applications”, to clients has been via networks such as the Internet through vehicles such as connected WWW (world wide web) browsers. Even with Java, which relieves partially the problem of code incompatibility, a human must still evaluate the framework or schema and design the interface. To reduce the inefficiencies inherent in such deployment of client UIs with their databases, there is a need to automate the building of UIs.
Further, where changes are made to the framework or schema of a data store, applications must then be re-programmed and re-compiled. Often, user interfaces are not made customizable, so that the same user interface would be presented to different users. Unless the UI is customizable and customizable in conformance with the framework/schema, the UI must be redesigned and reprogrammed (even using Java) if the user is to be able to run their desired UI. For instance, an engineer may not be as concerned about a portion of the database concerning financial information. Such a user may desire to have a UI that eliminates such information from his/her view. Thus, there is also a need to both enable customization and allow for changes to schema without the added cost, complexity and time of completely re-implementing the application.
SUMMARY
The invention is a method and apparatus for automatically and dynamically generating a user interface for a client based upon a database model. An application server creates a user interface description in accordance with the database model. The description is then distributed to the client, which interprets the description and creates the user interface therefrom. In some embodiments, a user may provide preferences and authentication to the application server which can create a modified description of the user interface.
REFERENCES:
patent: 5712960 (1998-01-01), Chiopris et al.
patent: 5812134 (1998-09-01), Pooser et al.
patent: 5818936 (1998-10-01), Mashayekhi
patent: 6014138 (2000-01-01), Cain et al.
patent: 6404445 (2002-06-01), Galea et al.
Noyau Eric
Wendker Andreas W.
Apple Computer Inc.
Nguyen Cao (Kevin)
Stattler Johansen & Adeli LLP
LandOfFree
Dynamic generation and automated distribution of user... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamic generation and automated distribution of user..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic generation and automated distribution of user... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3268983