WO2001080056A2 - Method and apparatus for applet-generated screen displays using computer database and programming language - Google Patents

Abstract

The present invention relates to the field of electronic screen displays and electronic data storage and retrieval. The apparatus includes a plurality of remote sites, a web server, and a database server. The database server includes a control box program for generating and interpreting pseudo code. A user at a remote site uses a web browser at a PC or workstation to access a web server hosting a database, application, and development toolkit. After the specific web browser of the user is identified, the web server downloads a web browser-specific applet. The downloaded applet acts as a screen engine and displays a data entry screen on the user's PC or workstation. The user enters data into a field on the data entry screen. The user triggers an event recognized by the applet. The applet responds to the event and, using its data delivey engine functions, evaluates the data entered into the data field for conformity with predefined criteria for the data field. The applet transmits the data, via the Internet/intranet to the web server. The data is applied to the control box program, which passes the data to the database. The database passes a response to the control box program, which then generates pseudo code, with is in turn transmitted, via the Internet/intranet to the applet. The applet updates one or more fields within an existing user screen or may generate one or more screen displays using the information returned to it from the control box program.

Description

METHOD AND APPARATUS FOR APPLET-GENERATED SCREEN DISPLAYS USING COMPUTER DATABASE AND PROGRAMMING

LANGUAGE

CROSS REFERENCE TO RELATED APPLICATIONS

The present application relates to U.S. Provisional Application No. 60/198,135, filed April 17, 2000, and U.S. Provisional Application No. 60/222,614, filed August 2, 2000, the disclosures of which are expressly incorporated herein in their entireties.

BACKGROUND OF THE INVENTION 1. Field of the Invention

The present invention relates to the field of electronic screen displays and electronic data storage and retrieval. 2. Discussion of Background Information

The rise of the Internet industry (e.g., e-business/e-commerce) has spawned a technical environment for new screen development tools. These products were developed to enable web-deployed systems and to provide a technical platform needed for businesses to operate via the Internet. Present screen development tools include Visual C++™, Visual Basic™, Visual J++™, and Visual M™. Web-based screen development tools include JAVA™, Visual Cafe™, HTML, and XML. The web-based screens designed using these tools can interface one screen at a time with various database products, including Oracle™, Access™, Sybase™, and Cache™. The problem is that programmers need to use two or more development tools in order to create a usable Internet/Extranet system. Typically a company needs experts in a screen design tool, an interface tool between the screen and database, and data management itself. Developing complex systems, such as healthcare systems, currently requires many programmers and a substantial amount of time in order to create a complete system. This can be very costly. Furthermore, web-based screen design tools do not have two- way communication with the database at a field level from an existing screen. This can create very inflexible web based screen applications. Generally, data management approaches are based on a two-dimensional database. A two-dimensional (or relational) database is based on a flat (or linear) filing structure that uses a predefined numeric structure to organize records. Each record occupies a predefined space along a continuum of all records. For example, record number 183 lies between record numbers 182 and 184. The location of each record is predefined, and the amount of space each record occupies also is predefined. As a result, the character length for record fields and the file size for each record must be pre- allocated, and they cannot be changed without a major restructuring of the entire database. The problem is a tremendous amount of wasted disk space and inflexibility in the database structure.

Additionally, current relational databases are not tied to an inherent programming language. Thus, there are no available built-in commands to, for example, create screen displays or to communicate two-way with a field on an already existing screen and the database. As a result, no new functionality can be added to the database. It acts merely as a filing structure, only capable of storing and retrieving data.

Presently, there are two main data management approaches structured on a two- dimensional relational database. The first approach may be classified as a "PC-to-PC" network approach. A PC-to-PC network approach may be structured as a PC-to-PC LAN. All software resides on each PC. Due to hardware limitations, a database may have to be fragmented into separate components and stored on separate PCs. This approach has the benefit of having the software processing speed optimized at each PC. Additionally, familiar Windows™-based interface and functionality of software may be found at each PC on the network.

However, a PC-to-PC network approach also has its problems. The fragmenting of the database minimizes data integration and interactivity. Additionally, there is a high cost for maintenance, because software updates and database backups must be performed at each PC. The PC-to-PC network software approach also lacks web functionality, except as a separate process not inherent to the software itself. Finally, because the PC- to-PC network approach is based on a low flexibility two-dimensional relational database, it lacks the ability to have a completely on the fly, hierarchy of data relationships and interactivity. Despite these limitations, the PC-to-PC network approach is still widely used in many industries. A second data management approach may be classified as a "legacy- system- attached-to-HTML-web-page." This approach typically uses a two-dimensional relational database and is structured on HTML or XML web pages based on standard, web-site design protocols. These pages draw upon a legacy mainframe system operating as a server that uses all the components of a two-dimensional/relational database to populate predefined fields on each web page. This approach offers greater flexibility in data retrieval by allowing users to access information on the mainframe database via the Internet. This second approach offers the benefit of a centralized database. With this benefit comes the efficient maintenance of the database using, for example, single-source updates and backups. A centralized legacy-system-attached-to-HTML-web-page also offers remote access via the Internet via a web browser and the ability to introduce JAVA applets to enhance interactivity between the user and the database. However, the legacy-system-attached-to-HTML-web-page approach has some problems. No new functionality is typically added to existing legacy systems. User interface speed is slow, due to one-way (server-to-browser) communication. The web browser screens are static, and the entire approach is heavily programmer dependent, thus making maintenance and updates to screens costly and time-consuming. More specifically, an Internet, Intranet, or network connect a user terminal to a remote web server with associated database. When the web browser loads onto a user terminal, a screen appears on the user's display. When a user triggers an event (e.g., a mouse click on an appropriate button on the screen), the entire screen disappears from the display. To the extent that data was previously entered into data fields on screen, the data is stripped (i.e., extracted) from the screen; all data, including fields left blank, are sent to the server. The web server then downloads a new screen definition to the user terminal. The user terminal, either independently or on command from the server, disposes of the existing page and displays a new page based on the new screen definition. The user perceives this as a refresh of a new page. SUMMARY OF THE INVENTION

If the above problems were overcome, the amount of information, the speed of transmission, overall system performance, and system flexibility would be significantly improved. A web-based system would be able to function much more like a standard WINDOWS™ based system and have a similar look and feel. The present invention relates to a method and apparatus for generation of screen displays using a scalable, web-based, multi-dimensional dynamic database. The invention allows for the adding or updating of one or more screen elements on an already existing screen. The invention provides for variable access and interactivity with multiple users to achieve complex functions in real-time via an Internet/Extranet interface. The present invention may be embodied in a suite of programs that function as a fully integrated, web-deployed, and interactive data management system. Other exemplary embodiments and advantages of the present invention may be ascertained by reviewing the present disclosure and the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES The present invention is further described in the detailed description which follows, in reference to the noted plurality of drawings by way of non-limiting examples of certain embodiments of the present invention, in which like numerals represent like elements throughout the several views of the drawings, and wherein:

FIG. 1 illustrates the apparatus of a preferred embodiment of the present invention.

FIG. 2 illustrates the structure of a database. FIG. 3 is a flowchart showing a method of providing access to a database application.

FIG. 4 is a flowchart representation showing another method of providing access to a database application.

FIG. 5 is a flowchart representation showing a method of providing pseudo code to an applet.

FIG. 6 is a flowchart of an initialization of a screen display. FIGS. 7-10 are examples of display screens. DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE

INVENTION The particulars shown herein are by way of example and for purposes of illustrative discussion of the embodiments of the present invention only and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the present invention. In this regard, no attempt is made to show structural details of the present invention in more detail than is necessary for the fundamental understanding of the present invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the present invention may be embodied in practice. FIG. 1 illustrates a system embodying the present invention. The system of FIG. 1 includes a database server 10, a web server 18, and a plurality of remote sites 28. The web server 18 interfaces with each of several remote sites 28 via a communication network 26, such as the Internet. Remote sites 28 each may have a computer 30 or any sort of communications device (fixed or mobile) that can interface to the network 26. Remote site interface devices will be referred to hereafter as "PCs" or "workstations" for convenience without intending to limit the generality of the remote sites.

The web server 18 preferably includes an applet 20, a firewall 22, and a security function 24. The firewall 22 protects against unauthorized entry and is well known in the art. The security function 24 may be Secure Sockets Layer ("SSL") 128-bit encryption and may include authentication and password protection. The security function 24 is well known in the art and will not be discussed herein.

The applet 20 is stored in the web server 18 and is downloaded to each remote site 28 PC or workstation 30, 32, 34 etc. upon connection of the remote site 28 to the web server 18. Once the applet 20 is completely downloaded from the web server 18, it runs entirely within the PC or workstation 30, 32, and 34. The applet 20 may be based on a scripted programming language, such as, for example, JAVA. In the preferred embodiment, the applet 20 is based on the JAVA programming language, although other languages may be used. The database server 10 includes a database 12, an application 14, and a development toolkit 16. Preferably, database 12 is a Cache™ database. Cache™, a product of Intersystems, Inc., is a multi-dimensional database (B-tree, post-relational structure) which includes a programming language known as "M." Data may be imported from any type of database, including Cache™. However, the invention is not so limited, as other multi-dimensional and two-dimensional databases may also be used with the present invention.

Referring now to FIG. 2, database 12 preferably includes five components: data 36, screen elements 38, a "control box program" 40, data manager 42, and process tracking 44. As discussed below, data manager 42 provides an intelligent and dynamic database system, wherein each piece of data is aware of itself, its relationship to all other data, and its relationship to the database structure itself. The data 36 may be data that is read into the database from, for example, magnetic tape, CD-ROM, or some other mass storage device. The data 36 also may also be entered into the database by manual keyboard entry or other known forms of data input. The preceding examples of data and data entry are exemplary rather than limiting. The screen elements 38 represent data for a graphical user interface ("GUI").

Screen elements 38 include a file structure that stores information about how to set up a screen and the components that are part of that screen. For example, screen elements 38 keep track of locations of labels, check boxes, list boxes, text boxes, etc. Screen elements include information that allows an applet 20 (not shown in Fig. 2) to draw items to be displayed for a user, such as required fields for displaying each piece of data and background colors for screen displays. Screen elements 38 also include definitions of user events (e.g., actions that will trigger an action, such as a mouse click or tab key depression by the user), that will trigger a response.

The control box program 40 is a program including a series of commands (in pseudo-code language) that are triggered by a user event. Pseudo-code commands execute predefined program objects that are used by system designers. Pseudo-code commands control interactions among the data 36, data manager 42, screen elements 38, process tracking 44, and remote sites 28 (FIG. 1). The control box program 40 also sends information to the remote sites 28 using pseudo-code that is interpreted by a downloaded applet 21. For example, the Control box 40 may send a complete screen definition. A screen definition includes the screen element 38, data 36, and any data dictionary 50 information necessary to display the GUI screen. Or, by example, the Control box 40 may send information to update or add one or more screen elements to an existing GUI screen. The remote sites 28 send to the control box program 40 a block of information, which may contain information including data values stored in data fields and associated identification information (possibly including the tracking information discussed below), but without sending all of the screen specification information. The data transfer only occurs in complete predetermined blocks of information, thus avoiding corruption. Process tracking software 44 creates a log of all user information and activity and maintains information about an environment so that a user may return to any interrupted process at any time. Interrupted processing with the remote site 28, coupled with the processing power of the downloaded applet 21, minimizes the need for communication with the database. Consequently, significantly fewer database hits occur, and fewer system access ports are required.

Process tracking 44 performs the following user activity. 1) Assignment of a unique process tracking number 46 to each PC or Workstation

30, 32, 34 when the user first signs-on, and tracking of all required system level data (i.e., user and security) for proper authentication.

2) Assignment of a unique application number 48 under the process tracking number 46 for each application that the user opens which (a) keeps track of temporary information used by each application, (b) is setup by the programmer, and (c) allows for a single application (reference screen) to be open for multiple users.

3) The application (reference screen) at the remote sites is tagged with the process 46 and application 48 numbers for user tracking purposes. When data is sent to the database server 10, the process tracking number 46 and application number 48 are also sent.

The database 12 is preferably structured as a "multi-dimensional" database. Unlike a two-dimensional database, a multi-dimensional database has a nonlinear structure that allows for minimized system response times and maximized data storage efficiency. Two-dimensional databases, in contrast, have a linear structure and have at least four major disadvantages relative to multi-dimensional databases. Each disadvantage will be discussed in turn.

1) Large, unused disk space. Because record space in a two-dimensional database is predefined, each record field length is also predefined. Field lengths must be set very high to accommodate as many entries as possible, without cutting off longer entries. When actual field entries are shorter than the predefined length, the extra space remains unused. As the number of records increases, the amount of unused space also increases. One example would be an address field that has been pre-allocated to accept 80 characters. If the address of a particular record only contains 15 characters, such as "123 15^th Street," 65 character spaces (or 81.25%) of that field remain unused. The amount of unused disk space can be enormously high considering that the number of records stored in a database can be in the millions. Additionally, extra space for each record must also be pre-allocated to accept future data fields, further increasing the amount of unused space. In contrast, record space in a multi-dimensional database is variable.

2) Limited number of records. Because record size is predefined and pre- allocated in a two-dimensional database, the number of records is limited by the size of the storage space available to the database. One example would be a database system that uses a 4GB hard drive to store its records where each record has been predefined to take 1MB of disk space. As a result, the database is limited to only 4000 records. Even though the hard drive has unused space upon reaching 4000 records, a new drive must be added to accommodate more records. In contrast, the number of records in a given storage space may be variable in a multidimensional database.

3) Limited number of characters. In a two-dimensional database, pre-allocation of storage space also limits the length of each data field. Entries needing more character spaces than available will be cutoff or misread. Adding extra space in records requires a complete restructuring of the database, which is extremely costly and time consuming. One example would be a date field that has been predefined to hold 6 characters

("MMDDYY"). "123199" is read and understood as December 31, 1999 by the system. A problem arises when January 1, 2000 must be entered into the database. If entered as "010100", it may be interpreted by the system as January 1, 1900. This "minor" glitch was the cause of the "Y2K" problem. In contrast, data fields may vary in length in a multi-dimensional database.

4) Slow system response time. Due to the linear structure of a two-dimensional database, data retrieval must also be linear, which results in a slow system response time. For example, to retrieve data from record number 183, the system must search from record 1 through 182, to find 183. As the number of records grows to the millions, the system response time becomes highly inefficient. An indexing scheme has been added to some two-dimensional databases which ameliorates, but does not fully overcome, this problem. Indexing allows the system to go directly to record 183 by storing information on the location of record 183. Though data retrieval time is improved, indexing creates new problems. Indexing is time-and resource-intensive. During indexing, system response speeds can actually go down. As a result, it requires long low-usage periods to execute the indexing, both to maximize the availability of system resources and to minimize its effect on users. Most systems are indexed during the late evening through early morning hours, when usage is considered low. This is problematic when viewed from a global perspective. As the Internet connects the global communities, low-usage periods will not be determined by time zones. In effect, low-usage periods will be minimal or nonexistent. Record size and location in a multi-dimensional database are not predefined. As a new record is entered into the system, its data can physically be located anywhere on the storage system and occupy only the space needed to represent that information. Infinite flexibility and expandability are possible because of an "on-the-fly" tagging process based on key fields in the file structure 54. This process allows the database 12 to access the location of each record based on data definitions 42 (FIG. 2) that define a record's relationship to other records. As data 36 is being entered into the database 12, the data 36 is tagged with a code and automatically sorted. This on-the-fly tagging process allows for optimized system response and data retrieval times. Any record can be found quickly, irrespective of the size of the file. Therefore, there is no predefined limit to the size or number of records in the database 12. The database 12 structure itself is infinitely flexible and expandable.

Cache™ includes a programming language known as "M" which allows for data to be "aware" of itself, its relationship to all other data, and its relationship to the database structure itself. Alternatively, a language separate from the database, but which could interact with the database to manipulate the data could generate screens, etc., could be used in the same manner. Data manager 42 predefines the type of data (as stored in the data dictionary 50), its record structure 52 and file structure 54. The data dictionary 50 contains definitions for each item of data and indicates the location where data 36 is stored. The record structure 52 contains the location for all stored data 36.. The file structure 54 contains the file name and a listing of records stored as data 36.

Additionally, the file structure 54 identifies key fields and sorts the records accordingly (i.e., the tagging process). Data manager 42 also links data 36 to screen elements 38. This linking of data 36 to screen elements 38 eliminates the need for preprogrammed GUI screens. These functions are further described below. Each application 14 is created from the development toolkit 16. The development toolkit is operable through, for example, simple English commands and graphical representations of commands. Therefore, development, modification, and enhancements may be conducted by systems analysts as opposed to programmers, thus preferably reducing the cost for application development and modification. The toolkit 16 also allows a user to create or edit the entire application (screen and database) using only the one development tool. Further cost savings may be realized because of the reduction in time required to develop or modify a program.

The development toolkit 16, which comes with database 12, may be a fully integrated suite of rapid application development tools used to develop and enhance specific iterations of the present invention in a web-based environment. The preferred embodiment includes a user-friendly interface, uses industry-standard terminology, and is structured as an easy-to-use set of functions based on commands associated with the control box program 40. These functions may include screen design, database design, pseudo-code generation, and external interface creation (both file and transactional types).

Using the development toolkit 16, many of the tasks traditionally performed by programmers can preferably be assigned to systems analysts. A systems analyst can design and modify applications with little or no knowledge of programming. This minimizes the heavy dependence on costly programmers and increases the use of more affordable systems analysts in the application development process.

Additionally, the application development process is streamlined and optimized, because systems analysts may have direct interaction with clients (i.e., users), and systems analysts also may have industry-specific knowledge. Modifications, such as adding a new data entry field, can be deployed in less time that would have been previously required for programmers to write code to perform the same function. New industry-specific applications can be developed and deployed at a fraction of the cost and time traditionally necessary. Global changes to the system can also be made at a single instance. Additionally, in the preferred embodiment, the toolkit is browser based, allowing the user to manipulate it while being on-site.

Because programmers are mostly removed from this development and enhancement stage, they can concentrate on developing new and advanced functionality within the database 12, application 14, and/or development toolkit 16.

JAVA is a programming language optimized for Internet use. JAVA allows a user to add more functionality than, for example, HTML or XML languages (collectively described hereinafter as "HTML"). HTML enables users to create simple GUIs such as text boxes, drop down boxes, and check boxes using simple commands. In HTML, once a send button or other equivalent button is clicked, information in all of the fields, (even fields where data has not been entered) is sent to the web server. HTML may be thought of as a one-way system; there is no two-way interactivity between the user and the database. JAVA is a scripting language in which a programmer expresses a set of commands to create a desired GUI which, in this embodiment, is interpreted by a browser.

In the preferred embodiment of the invention, a JAVA program (preferably an applet) will allow for two-way communication between the user and a database. The JAVA applet also has a number of data editing capabilities. Thus, for example, if a user entered a text character into a data entry field reserved for a numeric string, then upon the occurrence of a triggering event (such as the tabbing-out of the data entry field), a JAVA script would alert the user that an invalid character had been entered into a numeric field. This two-way local interactivity benefits the web server by reducing the number of hits on the server. It also improves speed because, if the information was entered into the data field correctly, then only that information need be sent back to the web server, as opposed to sending the data from the entire display screen back to the web server. In HTML, if a user filled in one text box then all of the text boxes (even if empty) are sent back. HTML cannot send a single field back unless that field is itself connected to a send button, of some sort. The sending of an entire screen display worth of fields consumes a great deal of web server time because all of the data from the screen display, whether needed or not, is being transmitted to the web server. Reducing the amount of data transmitted to the web server and ensuring that the data is correct prior to transmission to the web server, represent improvements over prior art in the field of web based data entry and retrieval. The less data applied to the web server, the faster the web server can react to the data.

The downloaded applet 21 may function as a dynamic screen and data delivery engine. In the preferred embodiment, the downloaded applet 21 can run on any JAVA- enabled web browser. The downloaded applet 21 is used to send and receive (i.e., two- way communication) pseudo-commands between the application and the user, and to then interpret and transform the pseudo-commands into a familiar Windows-based GUI, which is displayed through the web-browser on the PC or workstation 30, 32, 34.

This two-way communication is optimized for speed because the applet 20 is fully downloaded to the remote site's 28 PC or workstation 30, 32, 34 (i.e., user) upon connection to the web server 18. The downloaded applet 21 performs at least two main functions: 1) screen engine and 2) enhanced data delivery engine.

As a screen engine, the downloaded applet 21 receives and interprets pseudo- commands sent from the 12, and translates them into GUI screens and their components with which a user can interact. The screen engine can draw context-sensitive, interactive, and dynamic screens. The screen engine may be asked to update a screen component or attribute on an already existing screen display or create an entirely new screen display.

Under current HTML models, screens are static and must be based on predesigned pages. If a user requires information for which a screen has not been developed, a programmer must design that screen. This process is complex, costly, and time consuming.

Additionally, system administrators may decide that the number of requests for that information is too small, relative to the high cost of development. As a result, the user must refer to alternate, more traditional forms of information retrieval, such as retrieving data from paper records.

By contrast, the downloaded applet 21 in conjunction with the data manager 42 eliminates this tradeoff between time, cost, and limited information availability by providing instant access to all database information. The development toolkit 16 permits this rapid response to user requests for system modification. Additionally, the downloaded applet 21 minimizes hits against the server and improves response times by sending only those requests or screen components needing server responses. The control box program 40 sends small packets of information containing pseudo-code. The pseudo-code includes the information required for the downloaded applet 21 to create a set of commands with attributes to allow the downloaded applet 21 to create screens and events, for example.

The combination of pseudo-code directed toward the downloaded applet 21 and data delivery back to the control box program 40 of small amounts of data, make the preferred embodiment of the invention a thin client application. The data sent by applet 21 preferably includes the information entered into the field, and any other information necessary to identify that information (e.g. the field and screen where the information was entered). The data may also include information from previous fields on the screen along with associated identification information.

The downloaded applet 21 can also function as an enhanced data delivery engine by automatically validating and formatting user-provided data. It can also fill related data fields based on user-provided data. These data delivery engine functions happen before final data is delivered to the database 12. These predefined features allow the downloaded applet 21 to automatically recognize and decipher valid and invalid data and to respond accordingly.

Three key enhancements of the present embodiment of the downloaded applet 21 include: 1) auto-validation, 2) auto-fill, and 3) auto-format.

Using auto-validation, fields within the downloaded applet 21 GUI can be predefined to accept only specific data content or format. If the user enters invalid data, he/she is directed to the invalid data field, informed of the error, and prompted for corrections. This process eliminates the filing of invalid data and reduces the amount of network traffic (hits against the server), because invalid data is detected and corrected before being sent to the server. For example, a social security number field can be predefined to contain only nine numeric characters. If a user inputs either non-numeric characters or an invalid number of characters, the downloaded applet 21 will direct the user to the social security number field, display an error message, and prompt the user to make corrections. Using auto-fill, data fields within the downloaded applet 21 GUI can be predefined in the data definition 42 (FIG. 2) to recognize their relationship to other data fields and automatically populate or create related fields. Because these relationships are predefined, the auto-fill feature works nearly instantaneously through a two-way communication with the database 12. This may eliminate tedious data entry procedures for users and may drastically reduce erroneous data filing. For example, a zip-code data field can be predefined to recognize (as defined in the data definition 42) its relationship to the city and state fields. Once a user enters a zip code, the downloaded applet 21 can quickly query the database and automatically enter the city and state field with the corresponding data. This occurs without the user terminal (either independently, or on command from the server) disposing of the current page on the display. Disposing of a page is when a screen display (window) is removed and no longer viewable. Using auto-format, data fields within the downloaded applet 21 GUI can be predefined to reformat user entries based on industry-standard or client-specified protocols. This feature facilitates efficient and accurate data searches and retrievals by eliminating formatting inconsistencies within the database 12, which can result in multiple entries of the same information. For example, a "last name" field can be predefined to reformat any entry to all upper-case characters. If a user enters a last name in any combination of lower and upper cases, the downloaded applet 21 will automatically reformat the entry to all upper case, thus eliminating duplicate entries due to inconsistent formatting.

Through the downloaded applet 21, the "M" formatting conventions (auto- validation, auto-fill, and auto-format) are now available via a web browser (i.e., on a PC or workstation 30, 32, 34) connected to the Internet/intranet 26, for the first time.

FIG. 3 is a flowchart showing a first method of providing access to a database application. At step 56, a user at a remote site 28 (FIG. 1) enters an address for web server 18 (FIG. 7). Upon connecting to the web server 18 at step 58, web server 18 downloads a web-browser-specific applet 20 (either simultaneously with or following download of an HTML based web-browser screen) to the remote site 28 to create the downloaded applet 21. At step 62, the downloaded applet 21 triggers the control box program event that assigns a unique process tracking number 46 to the particular instantiation of the applet and triggers a sign-on security screen. FIG. 8 illustrates an exemplary security screen 134 generated by the applet 21.

At step 64, the user enters log-on information. At step 66, the user triggers an event, for example, by mouse clicking an "OK" sign-on button on the display screen. At step 68, the control box program 40 recognizes the event and validates the user. At step 70, the control box program transmits (1) an instruction to dispose of the previous screen, and (2) screen definition information for the applet to create a menu at the remote site 28. FIG. 9 is an example of a menu screen 136 with several menu elements accessed. At step 72, the user triggers an event, for example, mouse clicking on a menu item on the display screen. At step 74, the control box program 40 transmits screen definition information for the applet 21 to create a screen application. At step 76, the user interacts with the application screen. FIG. 10 illustrates an application screen 138 with data fields that have already been filled in (either by the user or the auto-fill feature). The following diagrams Fig. 4 through Fig. 6 describe the user interaction with a single data entry field on a screen.

FIG. 4 is a block diagram showing a method of use of an embodiment of the invention. In the illustration of FIG. 4, the user is attempting to transmit invalid data to the database 12 via the user's web browser. This illustration exemplifies the two-way communicative nature of the present invention. At step 78, a user at a remote site 28 uses a web browser at a PC or workstation 30, 32, 34 to access a web server 18 hosting the database 12. At step 80, after the specific web browser of the user is identified, the web server 18 downloads a web browser-specific applet 20. At step 82, the downloaded applet 21 acts as a screen engine and displays a data entry screen on the user's PC or workstation. At step 84, the user enters data into a field on the data-entry screen created by the applet. The user can then perform several actions such as, for example, mouse click, tab, and/or enter, which the applet will interpret as an "event," either singularly, sequentially, or in combination. At step 86, for example, the user tabs-out of the data entry field, which triggers an event recognized by the downloaded applet 21. At step 88, the applet responds to the event and, using its data delivery engine functions, evaluates the data entered into the data field for conformity with predefined criteria for the data field. The downloaded applet 21 may, among other things, auto validate and/or auto format the data. For purposes of the illustration of FIG. 4, at step 90 the downloaded applet 21 informs the user that the data entered into the data field is invalid. Thus the downloaded applet 21 has interacted with the user in an example of two-way communication. Incorrect data has not been transmitted to the web server 18, thus speeding the web server's 18 performance for other users.

By way of non-limiting example, a screen may have a field for entering a first name. If a user then enters a name that includes improper characters (e.g., numbers) and enters the data by pressing TAB, applet 21 recognizes an improper format and advises the user (e.g., applet 21 displays an error message screen) without transmitting the incorrect data to web sever 18. This error correction thus occurs without having to (1) enter data in all of the fields or (b) sending the entire screen back to web server 18.

FIG. 5 is a block diagram showing another method of use of an embodiment of the invention. In the illustration of FIG. 5, the data entered by a user is valid, however the data comprises information that explicitly or inherently indicates that the database need not be queried. In other words, the control box program 40 need only operate upon the data. This illustration exemplifies the dynamic versatility of the present invention. At step 92, a user at a remote site 28 uses a web browser at a PC or workstation 30, 32, 34 to access a web server 18 hosting the database 12. At step 94, after the specific web browser of the user is identified, the web server 18 downloads a web browser-specific applet 20. At step 96 the downloaded applet 21 acts as a screen engine and displays a data entry screen on the user's PC or workstation 30, 32, 34. At step 98 the user enters data into a field on the data entry screen. At step 100, the user triggers an event recognized by the downloaded applet 21. At step 102, the downloaded applet 21 responds to the event and evaluates the data entered into the data field for conformity with predefined criteria for the data field (although this step may be omitted).

At step 104, the downloaded applet 21 transmits the data, via the Internet/intranet to the web server 18. At step 106, the data is applied to the control box program 40. In this example, the data has a function associated with it. The function associated with the data is not set to access the database 12; therefore the control box program 40 does not access the database. Rather, at step 108, the control box program 40 sends pseudo-code back to the downloaded applet 21 to, for example, perform a new screen display or disable a function on an existing screen display.

By way of non-limiting example, a screen may have a field for a person's employment status, and another field for employment information. If the user enters "unemployed" in the first field and presses TAB, applet 21 sends this information to control box program 40. Since the second field may be considered irrelevant (as the user has no employment information), control box program 40 sends instructions to the applet 21 to disable the employment information field. Preferably, both the entry of the data and the subsequent disabling of the field would occur without transmitting the entire screen of data back to the web server, or refreshing the screen upon receipt of new data/instructions (unless the instructions specifically call for a new screen). In another example, control box program 40 could send an error message to applet 21 in response to certain types of erroneous or incomplete data.

FIG. 6 is a block diagram showing another method of use of an embodiment of the invention. In the illustration FIG. 6, the data entered by a user is valid and the data requires that information be stored to, or retrieved from, the database 12. At step 110 a user at a remote site uses a web browser at a PC or workstation 30, 32, 34 to access a web server 18 hosting the database 12. At step 112, after the specific web browser of the user is identified, the web server 18 downloads a web browser-specific applet 20. At step 114 the downloaded applet 21 acts as a screen engine and displays a data entry screen on the user's PC or workstation 30, 32, 34. At step 116 the user enters data into a field on the data entry screen. At step 118, the user triggers an event recognized by the downloaded applet 21. At step 120, the downloaded applet 21 responds to the event and evaluates the data entered into the data field for conformity with predefined criteria for the data field (although this step may be omitted). At step 122, the downloaded applet 21 transmits the data, via the Internet/intranet

26 to the web server 18. At step 124, the data is applied to the control box program 40. For purposes of the illustration in FIG. 6, the function associated with the data was set to access the database 12; therefore the control box program 40 passes the data to the database 12. In the alternative, control box 40 may elect to access only screen elements 38, or a combination thereof. At step 126 the database 12 passes a response to the control box program 40. At step 128 the control box program 40 generates pseudo code which is transmitted, via the Internet/intranet to 26 the downloaded applet 21. At step 130, the downloaded applet 21 disposes of the previous screen and now generates a screen display. Thus, the response to the event triggered by the user at step 118, completes a round of communication with the database.

By way of non-limiting example, entry of appropriate identification data in the fields of FIG. 8 causes control box program 40 to send information/instructions to dispose of the screen (FIG. 8), and to generate the menu screen in FIG. 9.

In most complex software systems the location of stored data in a file and the different attributes of the data (is it a text or numeric field) is normally written in a manual document or is stored as comments within the program code itself. Because of this, no tool can be created to help with the software development since it is not stored in a format that is accessible to the system. A programmer is required to look up the documentation or the program code to understand how to make any changes to the system.

There are tools on the market that can locate stored data, and also include some definable data attributes. A drawback of these tools is that they cannot handle complex data relationships, and therefore require special programming code. However, once special programming code is written, the system no longer has access to that data structure. A programmer is still needed to understand the special data relationship written in order to make any changes to the system. In the present invention, all data types are predefined such that no special programming code is necessary, even for complex data relationships. The location of all data is defined in the data manager 42. The type and name of the data elements are stored in the data dictionary file 50. Records keep track of the location of each data element defined in the data dictionary 50. The different records that track each data element are stored in the record structure file 52. The storage location where the records are stored on the disk is called a file name and is stored in the file structure 54. Also stored in the file structure 54 are the keys (tags) used to locate the records in the file.

By way of non-limiting example, the following describes the Data Management hierarchy: File

File name

File keys

List of Records (see below) Records Record # 1 = DDN1 ^Λ DDN2 ^Λ DDN3 ...

Record # 2 = DDN10 ^Λ DDN11 ^Λ DDN12 ^Λ DDN13 ...

Etc. Data Dictionary: DDN (Unique Data Dictionary Name)

Full Data Dictionary Name Data type (see below) Data Types

TABLE

The TABLE data type allows a pre-defined list of values. Typically each value within a table will have a code, description and a flag indicating whether or not a user can select this value.

For example:

DDN = Sex

Code Description User selectable

M MALE Y

F FEMALE Y

O OTHER N

In the above example, the user can select either M or F. When the database engine files this data into the database, it files M instead of MALE in order to reduce the amount of space required to store the value. A table DDN may also make an indirect reference to another table DDN if the same table values are used. For example, to avoid recreating identical tables of state county codes every time data is stored (e.g., Patient's county code or Provider's county code), the DDN's have an indirect link to the original table. The Patient's county code and Provider's county code are thus indirectly tied to the State county code table. DATE

DATE data type causes dates to be converted to a century independent format for storage. When dates are extracted from the database they are automatically converted to a standard external date format. For example:

Stored Value External Value 0 12/31/1840

58286 07/31/2000

100000 10/16/2114

NUMERIC

NUMERIC ensures that the data is numeric. Due to the fact that NUMERIC values are often treated differently than text or GENERAL values, they can be used in a CALCULATED DDN. GENERAL

A GENERAL DDN causes the data received to be stored and displayed in the same fashion. No conversions are done on the data. COUNTER COUNTERS allow for the automatic assignment of sequential values.

COUNTERS may be system wide, customer specific, or file specific. CALCULATED

CALCULATED data type causes the value of the DDN assigned to it to be calculated from a predefined equation. The calculation may be straight arithmetic or a combination of arithmetic and other DDN values. For Example: DDN Calculation

AGE DOB\365.25

Calculated DDN's can also contain nested calculations. CONSTRUCTED CONSTRUCTED causes the DDN value to be derived by combining the values of one or more DDN's separated by a predefined delimiter character. REPLACED-WITH

REPLACED-WITH allows indirect reference to another DDN with the same meaning. For example, 'PROVIDER NAME' and 'REFERRING PROVIDER NAME', are both provider names. Both have the same data type and format and are stored in the same file. When the referring provider name is displayed, the system actually displays the provider name value using a MAPPED-KEY as a reference to the data. Another example is Patient, Insurance Subscriber and Visit Guarantor, for which demographic data are stored in the same file, but Patient address, Subscriber address and Guarantor address information must be extracted separately using a MAPPED-KEY DDN as reference.

MAPPED-KEY

A MAPPED-KEY allows a relationship between a key piece of data stored in one file with a record or set of records from another file. For example: The DDN 'VISITINTPRP' is the internal provider pointer of the visit provider and is stored with each visit. The 'VISITINTPRP' is a mapped key to the DDN 'INTPRP', which is the key used to uniquely identify a provider within the provider file. Therefore, the mapped key can be used to extract general information about the visit provider from the general provider file.

This works with the REPLACED-WITH DDN to make the indirect DDN different from its REPLACED-WITH DDN. CUSTOM

Allows custom program code to be written for a DDN. The System Analyst with the knowledge of the DDN understands the functioning of the program code. SWITCH

SWITCH allows either a TRUE or a FALSE value. MONEY

MONEY allows standard display and storage of values that are considered money. For example:

Internal (cents) External (Dollars)

0 0.00 50 0.50

500 5.00

5000 50.00

MULTI-LINE TEXT

MULTI-LINE TEXT DDN stores a block of text. The text block is stored as a whole rather than line-by-line. Likewise, when a block text is extracted from the database, it is extracted as a whole.

The data management system allows the System Analyst using the present invention tool the ability to create or change applications. Once a DDN is defined it may be used in many powerful ways. By way of non-limiting example: - A DDN may be associated with a screen component. Once the DDN is tied to a screen component, the system has the information necessary to retrieve the DDN value, validate the DDN, or to store the DDN value. - A DDN can import data from outside sources. When data from a file needs to be stored, each imported data value is assigned a specific DDN. Once assigned, the system has the information to validate and store the imported value. A DDN can export data to outside sources. A System Analyst can create an export file by assigning DDN's to specific locations on the export records. Once assigned, the system has the information to extract and create the export file.

The Data Management system can also be used to extract data for reporting purposes. The system is ODBC compliant, which allows third party reporting system the ability to view another's file structures, record structures, and data dictionary names.

The data manager 42 is a map to the stored data values in data 36. To store the data value for a DDN, the system looks up the file where the DDN is located. Once the file is known, the system uses the file structure 54 to look up what keys are needed, the record the data value will be stored in, and the DDN position in the data record that the data value will be stored in. The system then sets the data value into the proper position on the data record, creates a reference on-the-fly using the file name, file keys and record identifier of where the DDN data value will be stored, and stores the record containing the DDN value using the created file reference. To lookup a data value for a specific DDN, the system looks' up the file where the

DDN data value is located. Once the file is known, the system use the file structure 54 to look up the keys needed, the record where the data value for that DDN is stored, and the DDN position in the record. The system then creates a reference on-the-fly using the file name, file keys and record identifier where in the DDN data value is stored, extracts the record from data 36 using the created file reference, and extracts the data value from the record using the DDN position.

When the System Analyst uses the present invention to create an application, this process is preferably pre-programmed to automate much of the work normally done by programmers. A screen display process demonstrates how the screen elements 38, in conjunction with data manager 42 and data 36, transfer to a downloaded applet to generate a screen interface for use at a remote site.

Screen elements 38 stores the information that creates the screen frames and keeps track of the screen components on the frame. It also stores any DDN's associated with the various screen components. The following is a non-exclusive list of screen frame properties that may be sent to the downloaded applet for processing: AssignAppNumber

^'Indicates whether or not a new application number is to be assigned to the frame when it is created. Acceptable parameters include: True, which forces a new application number to be assigned; False, which causes the new frame to inherit the application number of its parent frame; and Retain, which is used when one frame is disposed and another frame is drawn to set the application number to the original frame that was disposed (typically used in multi-frame dialogs).

Background

Sets the background color of the frame. Values are typically specified in red, green, and blue format.

ExecuteOnClose

Identifies Control box code that will be executed when the user executes an appropriate control event (preferably the X control button) on the frame.

ExecuteOnlnit Identifies Control box code that will be executed once the frame has been completely drawn.

Enabled

Indicates whether the frame should be enabled (accepts user interaction) or disabled once it has been completely drawn. Acceptable values for this parameter include: True, for which the frame is automatically enabled when it is drawn (this allows the user to interact with the components on the frame); and False, for which the frame is disabled when it is drawn (this prevents a user from interacting with the components on the frame).

Event Allows an event to be placed on every component within the frame. This is typically used to enable shortcut keys within the frame.

Focuslnit

Identifies the name of the component that will receive the initial focus once this frame becomes visible. Foreground

Sets the foreground color of the frame. Values will typically be specified in red, green, and blue format. Height

Specifies the height of the frame in pixels.

Label

Specifies the text that will be displayed within the title bar of the frame. Modal

Indicates if this frame should be modal. Modal frames must be closed before their parent frames can be interacted with, this parameter may be True or False. Name

Identifies a unique name that is given to every frame. This name can be used to identify the frame for future commands.

Resizable

Indicates whether or not the user can resize the frame, although default frames are typically not resizable. This parameter may be True or False.

Text See Label. Text will always override Label.

Visible

Indicates whether or not the frame should be made visible to the user once it has been created. By default, frames are automatically visible. This parameter may be True or False. Width

Specifies the width in pixels of the frame.

XPos

Identifies the initial X position of the frame. Frame positioning is preferably specified in pixel offset from 0. The top left pixel on the screen is preferably X position 0.

YPos

Identifies the initial Y position of the frame. Frame positioning is preferably specified in pixel offset from 0. The top left pixel on the screen is preferably Y position 0 Several supported screen components may be sent to the downloaded applet and applied to a screen frame on the remote site. Non-limiting examples include: Button

A button is a raised area on the screen that when pressed will initiate a given action.

Check Box A check box is a component that has either an on or off (checked or unchecked) value.

Choice

Choice allows the user to select from a drop down list of choices. Preferably, only one item from the list can be selected. Horizontal Line

Displays a horizontal separator on the frame.

Image Viewer

Displays a gif or jpg image on the frame

Label Display only area that allows predefined or dynamic data to be displayed.

List

List is a rectangular component that displays a list of items for the user to select from. The user may select one or more items depending on how the component is configured. Numeric Spinner

Numeric Spinners allow the user to select a single number from a predefined range.

Rectangle

Draws a box on the frame. The box may be made to appear raised or lowered, giving a 3D appearance.

Text Area

Text Areas allow multi-line text to be entered.

Text Field

The text field allows a single line of text to be entered. Control box program 40 generates a screen as follows. The system looks up the different screen frame properties (described above) for the screen display requested and sends pseudo code based on the frame properties to the downloaded applet at the remote site. The system then looks up the different screen components (described above) for the requested screen. If a screen component has an associated DDN, the DDN properties are looked up in the data dictionary 50. The system may also look up the data value associated with the DDN, using the data management process (described above). The system sends pseudo code based on the screen components, DDN properties and DDN data values to the downloaded applet at the remote site. When the control box program 40 is finished with the triggered event, it sends a process-completed flag to the downloaded applet. The applet interprets all of the received screen display pseudo code sent to generate a user screen, which will appear to generate the screen display all at once rather than component by component.

It is noted that the foregoing examples have been provided merely for the purpose of explanation and are in no way to be construed as limiting of the present invention. While the present invention has been described with reference to certain embodiments, it is understood that the words used herein, are words of description and illustration, rather than words of limitation. Changes may be made, within the purview of the appended claims, as presently stated and as amended, without departing from the scope and spirit of the present invention in its various aspects. Although the present invention has been described herein with reference to particular means, materials and embodiments, the present invention is not intended to be limited to the particulars disclosed herein; rather, the present invention extends to all functionally equivalent structures, methods and uses, such as are within the scope of the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A method of communicating between a database and a remote site over a network, comprising: sending a screen definition from the database to the remote site over the network, the screen definition including a definition for a plurality of data entry fields; and receiving at the database from said remote site data associated with less than all of said plurality of data entry fields.

2. The method of claim 1, said receiving further comprising receiving information relating to the screen definition.

3. The method of claim 1 , further comprising sending to the remote site, after said receiving, information associated with the data, without sending an updated screen definition in association with the data.

4. The method of claim 1, further comprising sending, after said receiving, an updated screen definition to the remote site without sending instructions to dispose of at least substantially all of the screen definition.

5. The method of claim 1, further comprising: storing a plurality of sets of information at the database; identifying, at the database, at least one of the sets of information that corresponds to the data; and sending the at least one of the sets of information from the database to the remote site.

6. The method of claim 1, further comprising downloading an applet to the remote site, wherein the applet receives the sent screen definition, and sends the data to the database.

7. The method of claim 1, further comprising sending, after said receiving, instructions to the remote site to disable at least a portion of a screen corresponding to the screen definition.

8. A method of communicating between a database and a remote site over a network, comprising: receiving a screen definition at the remote site from the database over the network, the screen definition including a plurality of data entry fields; generating a displayed screen based on the screen definition; sending originating data from less than all of the data entry fields from the remote site to said database over the network; receiving updated data associated with the originating data; and displaying said updated data without disposing of all of the displayed screen.

9. A method of communicating between a database and a remote site over a network, comprising: receiving a screen definition at the remote site from the database over the network, the screen including a plurality of data entry fields; generating a displayed screen based on the screen definition; sending originating information entered into at least one, but not all of the data entry fields from said remote site to said database over said network.

10. The method of claim 9, said sending further comprising sending information to the database relating to the screen definition.

11. The method of claim 9, further comprising: receiving, after said sending, additional data associated with the originating information; and displaying the additional data without refreshing the displayed screen.

12. The method of claim 11, wherein said displaying further comprises displaying said additional data in appropriate ones of said plurality of data fields.

13. The method of claim 9, further comprising receiving, after said sending, an updated screen definition at the remote site.

14. The method oi^* claim 13, further comprising receiving, after said sending, instructions to dispose of the screen definition at the remote site.

15. The method of claim 9, further comprising checking, prior to said sending, the data entered into the data entry field against predetermined criteria.

16. The method of claim 15, further comprising reformatting, in response to said checking, and before said sending, the data entered into the data entry field to comply with the predetermined criteria.

17. The method of claims 15, further comprising blocking said sending if the data entered into the data entry field does not meet the predetermined criteria.

18. The method of claim 9, further comprising: receiving, after said sending, instructions to disable at least a portion of the displayed screen; and disabling the at least a portion of the displayed screen.

19. A method of communicating between a database and a remote site over a network, comprising: downloading a program to the remote site; sending a screen definition from the database to the remote site over the network, the screen definition including definitions that can be used to generate a plurality of data entry fields; the program generating a displayed screen at the remote site based on the screen definition; and the program sending information entered into at least one, but less than all, of the data entry fields from the remote site to said database over said network.

20. The method of claim 19, further comprising: the database identifying at least one of an updated screen definition and non- screen data corresponding to said information; the database sending the results of said identifying of the remote site; the program, in response to only receiving only the non-screen data, displaying the non-screen data in appropriate fields of the plurality of data fields; and the program, in response to only receiving the updated screen data, replacing the displayed screen with an updated displayed screen based on the updated screen definition.

21. The method of claim 20, wherein the program is a web browser based applet.

22. A method using a computer applet to generate screens and evaluate data, comprising: downloading an applet into the computer through a network from a server; generating, with the applet, a data entry/data display screen having at least one data entry field; entering data into at least one of the at least one data entry field; detecting, with the applet, an event triggered by the user; and evaluating the data for conformity to predefined criteria.

23. The method of claim 22, further comprising notifying, with the applet, the user that the data does not meet the predefined criteria.

24. The method of claim 22, further comprising automatically reformatting, with the applet, the data to conform to the predefined criteria.

25. A method using a computer applet to generate screens and to transmit data to a server, comprising: downloading an applet into the computer through a network from a server; generating, with the applet, a data entry/data display screen having at least one data entry field; entering data from a user into the field; detecting with the applet an event triggered by the user; performing, with the applet, an evaluation function on the data, wherein the evaluation function evaluates the data for conformity to predefined criteria; and transmitting, upon positive evaluation of conformity to predefined criteria, the data from the applet to the server.

26. A method using a computer to retrieve data from a database server through a network, comprising: downloading an applet into the computer from a communication server; generating, with the applet, a data entry/data display screen having at least one data entry field; entering data from a user into the field; detecting, with the applet, an event triggered by the user; transmitting the data from the applet to the database server; evaluating, at the database server, a variable associated with the data, wherein the variable indicates that the database need not be queried; generating, at the database server, pseudo codes for a new screen display; transmitting the pseudo codes to the applet, via the communication server.

27. A system for providing access to a central database from a database, said database configured with a communication program capable of initiating a communication session with a communication server via a shared network and, during such a session, receiving and executing at least one applet from a communication server, said system comprising: a database of stored information accessible in accordance with a predetermined command set; a control box program capable of regulating access to the database by communicating commands of the predetermined command set to the database, communicating data to the database, and receiving data from the database; a communication server providing a link between a control box program and a shared network; and at least one applet that can be downloaded from the communication server to the database, said applet being capable of generating user interface screens at the database, detecting user-triggered events and the database, performing at least one evaluation function on data input by a user to the database; and communicating a result of the at least one evaluation function to the control box program; wherein the control box program processes the result of the at least one evaluation function and regulates access to the database in accordance with the processing of the at least one evaluation function.

28. The system of claim 27 wherein: the applet is capable of generating an interface screen with fields for a plurality of pieces of data to be input from a user; and upon receipt of less than all the plurality of pieces of data by the user, the applet is capable of initiating a communication to the communication server that results in a return from the database of data associated with the data input by the user.

29. The system of claim 27, wherein the control box is capable of generating pseudo code for communication to an applet as a result of processing the result of the at least one evaluation function received from an applet.

30. A system for communicating between a first site and a second site, comprising: a screen definition database and a non-screen database at said first site; a web-browser based applet at said second site; a control at said first site, said control being capable of sending a screen definition from said screen database to said applet; said applet being capable of generating a display screen based on said screen definition, said displayed screen having a plurality of data entry fields; and said applet being capable of sending to said control data entered into at least one, but less than all, of said data entry fields.

31. The system of claim 30, further comprising said control being capable of sending to said applet, in response to receipt of data entered into at least one of said data entry fields, one of an updated screen definition from said screen definition database, data from said non-screen data base relating to said data entered into at least one of said data entry fields, and instructions that do not require access to either of said screen definition database and said non-screen database.