EP1266283A1 - Navigateur de recherche dynamique d'applications et base de donnees a cet effet - Google Patents

Navigateur de recherche dynamique d'applications et base de donnees a cet effet

Info

Publication number
EP1266283A1
EP1266283A1 EP99967210A EP99967210A EP1266283A1 EP 1266283 A1 EP1266283 A1 EP 1266283A1 EP 99967210 A EP99967210 A EP 99967210A EP 99967210 A EP99967210 A EP 99967210A EP 1266283 A1 EP1266283 A1 EP 1266283A1
Authority
EP
European Patent Office
Prior art keywords
database
objects
computer
user
procedure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP99967210A
Other languages
German (de)
English (en)
Other versions
EP1266283A4 (fr
Inventor
Adam J. Rabung
Michael H. Schrag
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ANCILE SOLUTIONS, INC.
Original Assignee
Experience Technologies LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Experience Technologies LLC filed Critical Experience Technologies LLC
Publication of EP1266283A1 publication Critical patent/EP1266283A1/fr
Publication of EP1266283A4 publication Critical patent/EP1266283A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Definitions

  • the present invention relates generally to network computer systems, and more particularly to automatically updating of applications from one computer to another computer over a network.
  • Operating systems and Internet browsers are commonly used to allow a user to execute and/or read multiple applications and/or files.
  • a Microsoft ® Windows ® operating system allows a user to select an icon which represents an application. Upon selection of the icon, the application is run and the user is able to interface with the application.
  • an Internet browser such as Microsoft ® Internet Explorer
  • a user enters an Internet address which translates to a unique machine on the Internet which provides the user data which can be either viewed or run by the user.
  • One problem faced with operating systems and Internet browsers is the difficulty in updating individual modules of the operating systems and browsers.
  • the program (or a large amount of data) may need be deleted and a new program (or data) installed in its place.
  • the old program may be completely overwritten by the new program.
  • This process may require the user to actively participate in the updating of applications and files by having to manually replace existing applications and files with new applications and files.
  • this procedure can be time consuming, especially if only a minor change is to be made to the application.
  • Computer applications such as operating systems, Internet browsers, and other user application, typically use graphical user interfaces. These graphical user interfaces are characterized by the presentation of information in windows, as well as user control by a pointing device such as a mouse. The operation of these graphical user interfaces in such an environment can be described as "select-then- operate," i.e. , a user first selects an object from the interface and then indicates the desired operation for that object.
  • Graphical user interfaces built according to object oriented principles can be viewed as including three components: the model, the view, and the controller.
  • the model-view-controller (MVC) concept originates from a Smalltalk class- library as described in Design Patterns for Object-Oriented Software Development written by Wolfgang Pree, Addison-Wesley, 1995 and A System of Patterns written by Frank Buschmann et al. , Chichester, West Wales, John Wiley & Sons, 1996, the contents of which are incorporated here by reference in their entireties.
  • the model stores application-specific data, e.g. , a text processing application stores text characters in the model and a drawing application stores a description of different graphical shapes in the model.
  • a view presents the model on a display, e.g. , a screen. Any number of views might present the model in different ways although each view accesses the information stored in the model.
  • the controller handles input events such as mouse interaction and key strokes of a keyboard.
  • the controller can access the view as well as the model to make changes to both the model and the view.
  • Some applications that run on computers using the MVC approach are used as teaching utilities.
  • other applications are used so that the user can participate in commerce over networks such as the Internet. These applications may require information to be sent from one computer to another. For example, in an educational training program, a user may need to download educational material from a server as well as inform the server of its progress with the educational material.
  • electronic commerce a user may wish to execute a sale via keystrokes on his keyboard and have a message sent to a remote source so that an order for goods or services can be processed.
  • An application browser is provided which is run on a first computer including at least one database that stores a plurality of objects; an update module that uploads and downloads objects from a second computer; and a database manager that controls storage of, and access to, the objects stored in the at least one database and interfaces with the update module and the at least one database, wherein the at least one database includes at least one table storing at least one of the plurality of objects.
  • Figures 1A and IB illustrate a typical computer system of the type in which the present invention can be employed
  • Figure IC illustrates an exemplary embodiment of the dynamic application browser according to the present invention
  • Figure ID illustrates an exemplary object according to the present invention
  • Figures IE illustrates an exemplary table according to the present invention
  • Figures 1F-1G illustrate exemplary indices according to the present invention
  • Figures 1H-1L illustrate an exemplary embodiment of the file structure of a database according to the present invention
  • FIG. 2 illustrates an exemplary process performed by the startup module of the present invention
  • FIG. 3 illustrates an exemplary flowchart for the update step 230 of Figure 2
  • Figure 4 illustrates an exemplary flowchart for performing the install step
  • Figure 5 illustrates an exemplary flowchart of the autoload actions module 234 of Figure 2;
  • Figure 6A illustrates an exemplary embodiment of the insert object functionality of the database according to the present invention
  • Figure 6B illustrates an exemplary embodiment of the indexing step 6220 of Figure 6A
  • Figure 7A illustrates a flowchart of an exemplary modify procedure performed by the database manager according to the present invention
  • Figure 7B illustrates an exemplary embodiment of step 7246 of Figure 7A;
  • Figure 8 illustrates a flowchart of an exemplary modify an object by condition procedure performed by the database manager according to the present invention
  • Figure 9 illustrates a flowchart of an exemplary query a table by condition procedure performed by the database manager according to the present invention
  • Figure 10 illustrates an exemplary embodiment of a procedure for deleting an object by its object ID according to the present invention
  • Figure 11 illustrates an exemplary embodiment of a procedure performed by the object database manager for deleting an object based on a condition according to the present invention
  • Figure 12 illustrates an exemplary embodiment of step 10514 in Figure 10
  • Figure 13A illustrates an outgoing table according to an exemplary embodiment of the present invention
  • Figure 13B illustrates an incoming table according to an exemplary embodiment of the present invention
  • Figure 13C illustrates a history table according to an exemplary embodiment of the present invention
  • Figure 13D illustrates a transport cell list according to an exemplary embodiment of the present invention
  • Figure 14 illustrates an exemplary embodiment of the procedure by which one computer sends data to another computer to which it is connected according to the present invention
  • Figures 15A-15C illustrate an exemplary installation procedure of the present invention
  • Figures 16A-16C illustrate exemplary structures of an application module of the present invention
  • Figures 17A-17J illustrate an exemplary interactive educational system application module of the present invention
  • Figures 18A-18D illustrate an exemplary embodiment step 9402 of Figure 9; and Figures 19A-19C illustrate an exemplary embodiment of step 6216 of Figure 6A.
  • the present invention may be embodied in a general purpose digital computer that is running a program or program segments stored on and originating from a computer readable or usable medium, such medium including but not limited to magnetic storage media ((e.g. , ROM's, floppy disks, hard disks, etc.), optically readable media (e.g. , CD-ROMs, DVDs, etc.) and carrier waves (e.g. , transmissions over the Internet or Intranet).
  • a functional program, code and code segments, used to implement the present invention can be derived by a skilled computer programmer from the description of the invention contained herein.
  • JavaTM is described, for example, in JavaTM Primer Plus by Paul Tyma, Gabriel Torok, and Troy Downing, published by Waite Group PressTM in 1996, the content of which is incorporated here by reference in its entirety.
  • JavaTM implementation and description is provided as an exemplary embodiment and is not meant as a limitation of the scope of the invention. It is within the skill of the ordinary artisan to implement the features of the present invention using other programming techniques and programming languages.
  • the present invention may be implemented on a variety of computer systems (such as IBM ® -compatible computers, workstations, etc.) equipped with an operating system, e.g. , Microsoft ® Windows ® 95/98.
  • an operating system e.g. , Microsoft ® Windows ® 95/98.
  • a typical computer system of the type in which the present invention can be employed, is illustrated in schematic view form in Figures 1A and IB.
  • the present invention is designed to run on a computer system which includes at least one network computer 100 and at least one client computer 101.
  • the client computer(s) 101 can communicate with each other or with the network computer 100.
  • the network computer 100 may be part of a larger computer network or data service or may be a single network server.
  • computer 103 includes at least one central processing unit (CPU) 105 which is connected to at least one input device 107, e.g. , a keyboard, mouse, touch pad, etc. , at least one memory unit 111 , e.g. ,
  • RAM and/or ROM and at least one storage device 113, e.g. , a hard drive, floppy disk drive, writeable CD/DVD, EEPROM, etc.
  • the modem 125 or network interface 127 may be connected to a computer network or data service via a wire or wireless connection.
  • the connection to a computer network or data service via the modem 125 and/or network interface 127 provides two-way communication.
  • data can be received by computer 103 via modem 125 or network interface 127, entered directly to the computer 103 via input device 107, or recalled from storage device 113.
  • output of the present invention may be displayed on at least one display device 115, stored in the storage device 113, or sent to another computer via the modem 125 or the network interface 127.
  • the system illustrated in Figures 1A and IB is implemented in at least two computers.
  • the two computers can have a client-server relationship or a peer-to-peer relationship.
  • a server computer can connected to multiple clients whereby each client can receive updates from the server and transmit data to the server via a dynamic application browser according to the present invention.
  • the client's dynamic application browser is running an educational application module
  • the dynamic application browser can receive education material, such as, lesson plans or exams from a server.
  • statistical data such as, test scores, usage time can be sent from the client to the server for evaluation.
  • profile data or other user information can be sent from the client to the server for identification.
  • the client can send data to the server authorizing the purchase of additional lesson plans or additional application modules.
  • the server can make changes to the application module being run on the client by updating individual JavaTM objects and class files without the need to replace the entire application module.
  • the server can make changes (or updates) to the client's dynamic application browser using the same techniques as those modifying the individual application modules.
  • Figure IC illustrates an exemplary embodiment of the dynamic application browser according to the present invention.
  • the dynamic application browser according the present invention is adapted to run on the computers 100 and 101.
  • the software that comprises the present invention will be described only as it is implemented on a client computer 101.
  • the present invention includes a startup module 102, an application module 104, a global settings module 106, an object database manager 108, and an update module 110.
  • the update module 110 includes a database gateway 112 and an update manager 114.
  • the object database manager 108 includes a handler manager 109.
  • the handler manager 109 is used to install data received from another computer in the local computer. This will be described with respect to Figures 13-15.
  • Each database 116, 117, 118 corresponds to a different application module (e.g. , application module 104). Alternatively, multiple application modules can share the same database or can each use multiple databases either exclusively or inclusively.
  • the startup module 102 controls the initialization of the computer 101.
  • the present invention can include one or more application modules, which are run by the dynamic application browser that comprises the present invention.
  • the application module 104 can be any type of application that may need the resources of an object database manager to retrieve and store objects in an object database.
  • the update module 110 performs updating of objects stored in the at least one database on the computer 101.
  • the object database manager 108 manages the databases.
  • the object database manager 108 controls the functionality of multiple databases 116, 117, 118. Each database stores tables 119 which include at one index 120, 121.
  • the databases 116, 117, 118 store objects 122 (or data) as elements of a table 119.
  • the elements in table 119 are then used to create one or more indices 120, 121 which allow the elements in the table 119 to be easily accessed.
  • only one type e.g. , objects of a particular class
  • the "type" of an object is defined as, for example, the structure and fields contained in the object.
  • Figures 1H-1L illustrate an exemplary embodiment of the file structure of the databases 116, 117, 118.
  • Each database 116, 117, 118 includes a database file (not shown) containing a list of all tables in the database.
  • each database 116, 117, 118 includes a file glossary file ( Figure IH) which maps all symbolic file names to physical file names (e.g. , the table names listed in the database file with physical file names).
  • a global file glossary file is used to map all symbolic file names for all of the databases 116, 117, 118.
  • Each table 119 has associated therewith a table file ( Figure II), a data file (Figure U), a file map ( Figure IK), at least one index file ( Figure IL), and a random access file (RAF) (not shown), all stored on a recordable medium such as a hard drive.
  • the table file includes information such as the type or class permitted in the table, a disk cache policy, the number and file names of the indices associated with the table, a symbolic name for the file map, and the file name of the random access file.
  • the index file contains a list of object IDs associated with the index values of the index. There is one index file created for each index of the table.
  • the index file also includes the class name describing the type of value stored in the index (e.g. , string, integer, or any other permissible JavaTM type), the name of a method (or procedure) which is called by the object database manager 108 to extract the index value from an indexed object, and a flag indicating whether there is a one-to-one relationship between objects and index values (e.g. , a social security number should have a one-to-one relationship with a person object since no two people share a social security number).
  • the file map includes a list of object IDs associated with file size and file offsets (file pointer values) in the random access file. Objects within the database are stored in a serialized form in the random access file and the file offset indicates the physical location of the serialized object.
  • the file map also includes the total size of the random access file, the end pointer value of the random access file, and the total number of objects stored in the random access file.
  • the data file includes the symbolic name for the random access file and the symbolic name for the file map.
  • An example of an object 122 is illustrated in Figure ID.
  • the exemplary object 122 of type "person" includes a unique identification field (ID), a first name field (FIRST NAME), a last name field (LAST NAME), and an age field (AGE).
  • ID unique identification field
  • FIRST NAME first name field
  • LAST NAME last name field
  • AGE age field
  • An example of a table for "person” objects is illustrated in Figure IE.
  • the object type may be any type available in JavaTM provided it can be represented as an array of bytes and provided it can have a unique object ID assigned to the object.
  • the exemplary table shown in Figure IE includes at least one object 122 of the "person” type.
  • An example of an index 120 is illustrated in Figure IF. The index 120 sorts each of the objects in the table 119 by, for example, its last name field.
  • the index 120 includes a last name value column and an object identification (ID) column.
  • Figure IF illustrates another exemplary index 121 which is stored by "FIRST NAME. " In this case, since objects with object IDs of 1 and 2 both contain a first name field having the same value, the index 121 lists both object IDs in the same row corresponding to the first name "Mark. "
  • the startup module 102 which controls the initialization of the computers 100, 101 will now be described.
  • the startup module 102 is connected to the global settings module 106.
  • the global settings module 106 initializes various parameters for the operation of the system. For example, the location of the various databases 116, 117, 118 can be stored in the global settings module 106.
  • the startup module 102 also interfaces with the object database manager 108 to reference, retrieve, and store items in the various databases 116, 117, 118.
  • the startup module 102 also interfaces with the update module 110 via the update manager 114.
  • the update module 110 assists the system in uploading and downloading objects from a remote computer, i.e. , either the network computer 100 or a client computer 101.
  • the update module 110 may be called by the startup module 102 during the initialization process to update the database 116, 117, 118 with any information that is transferred from another computer. Alternatively, the update module 110 may be called by the application module 104 to update the databases 116, 117, 118 on the local (executing) computer with information created by the application.
  • the update module 110 communicates with the object database manager 108 via database gateway 112.
  • Database gateway 112 serves as an interface between the database manager and the update module 110 so that the update module 110 can transfer new objects received from remote computers to the appropriate tables stored in the databases.
  • the database gateway 112 is able to convert the instructions to and from the update module 110 into commands which are understood by the database manager 108 as well as the update module 110.
  • a different database e.g. , any JavaTM Database Connectivity (JDBC) compliant database such as an SQL server
  • JDBC JavaTM Database Connectivity
  • the database gateway 112 automatically detects the type of database connected to it and converts the instructions to and from the update module 110 into commands which are understood by the database manager 108 as well as the update module 110.
  • an application module 104 which can communicate with any of the global settings module 106, the object database manager 108, and/or the update module 110, to run its specific application.
  • application modules 104 include games, educational training programs, electronic commerce programs, finance applications, and any other application which may need the resources of an object database manager to retrieve and store objects in an object database.
  • an application can utilize the update module 110 via the update manager 114 to send and receive information to and from a remote location, such as for example, product requests, product information, test scores, application updates, usage statistics, customer information, and/or additional application modules or portions thereof.
  • Figure 2 illustrates an exemplary process performed by the startup module
  • step 226 the global variables are initialized.
  • a global variable is a setting, value, or resource (i.e. , a reference to a database) that is referenced by one or multiple modules in the dynamic application browser. Since these global values are used throughout the use of the dynamic application browser (e.g. , in the startup procedure), it is necessary for their locations to be predetermined, such that the various modules of the browser can locate the various databases as well as information pertaining to the location, e.g. , Internet addresses of remote computers.
  • step 228 after initializing the global variables in step 226, the specific database 116 associated with a desired application module is located and the location of the specific database 116 is stored in the global settings module 106. In the embodiment currently implemented, there is only one application module available for execution.
  • the update module 110 sends and receives objects to and from a remote location, e.g. , the network computer 100 or other client computer 101 , connected via a network or Internet connection.
  • the new objects received by the update module 110 are then installed in the appropriate database corresponding to the application module in step 232.
  • the default or the selected application module 104 is loaded by initiating a standard setup protocol such as initializing the model, view, and controller for the application module 104.
  • FIG. 3 illustrates an exemplary flowchart for the update step 230 of Figure 2.
  • a database gateway 112 is accessed to interface with the object database manager 108.
  • the location of the database gateway 112 is stored as a global variable in the global settings module 106 in step 338.
  • the startup module 102 verifies that update support is enabled. If update support is not enabled (e.g. , no network connection is present), the update process is skipped in step 347. If, however, update support is enabled, a login prompt is created and displayed to a user of the local terminal in step 342.
  • the user enters a user name and password, for example, which is then stored in a file in step 346.
  • a status panel is displayed to the user in step 348 to inform the user of the status of the update procedure and also to prevent the user from thinking that the system has stopped operating properly due to the potential delay caused by the update module.
  • the user information is sent to the network computer from the client computer.
  • the network computer 100 authenticates the user and sends back a message indicating whether or not the authentication was successful.
  • new objects which were designated to be exchanged between the two computers, and particularly, in tables containing any transport cell lists (described below with respect to Figures 13-16), are exchanged.
  • the authentication was unsuccessful, an error message is generated and displayed to the user (not shown). The user may be prompted again or the program may shut down.
  • step 352 the startup module verifies that the update process was completed successfully. If yes, the update process ends in step 358, otherwise, an error message is created and displayed to the user in step 356.
  • FIG 4 illustrates an exemplary method for performing the install step 232 of Figure 2.
  • the startup module 102 checks with the update module 110 via the update manager 114 to see if any new objects have been received from any of the remote computers via the exchange of transport cell lists from step 350. If no new objects are present, the install procedure is skipped in step 462. If, however, there are new objects present, a status window is displayed to the user in step 464 and the installation of the new objects in the database is begun in step 466.
  • An exemplary installation procedure is described with respect to Figures 15A-15C, below. After the installation of the new object is completed in step 466, the installation is made permanent by committing the changes to disk in step 468.
  • step 470 the status window is removed and in step 472, the startup module 102 verifies that the install procedure has been completed successfully. If the install procedure 232 has been completed successfully, the install procedure 232 ends in step 474. Otherwise, if the install procedure 232 did not complete successfully, an error is reported to the startup module 102 on step 476.
  • Figure 5 illustrates an exemplary embodiment of the autoload actions module 234 of Figure 2.
  • a table from the database is retrieved from which contains a list of actions that are to be performed by the autoload actions module 234.
  • Actions are defined, for example, as procedures instructing the dynamic application browser to perform a specific task, such as, start an application module, create a new database, or modify the structure of an existing database.
  • each action contains a priority value.
  • the actions are sorted in order of priority so as to perform the action with the highest priority first and the action with the lowest priority last and so forth.
  • step 582 the autoload actions 234 verifies to see if there are actions to perform by referencing a counter which represents the total number of actions in the table retrieved in step 578. If the counter equals the total number of actions that have been performed, then the autoload actions module 234 is completed in step 584. If the counter is less than the total number of actions that have been performed, then the next action is evaluated to determine whether or not it is a conditional action in step 586.
  • a conditional action is an action which is only to be performed based on the occurrence of certain events. For example, an action may only need to be performed if it has not been performed in the past. That is, for example, the action may be to initialize a new database and would be unnecessary if the database already existed.
  • an action can be conditional based on the time of day or day of week, or any other condition which can be evaluated and can return a boolean value. If the current action is not conditional then the action is performed in step 588. Otherwise, the condition is evaluated in step 590. If the condition evaluates to true then the action is performed in step 588, otherwise in step 593 the counter is incremented and the process returns to step 582.
  • the startup module 102 determines whether or not the action created an object which represents an application module 104. If the action created is determined to be an application module 104, the application module is executed in step 596 and the startup module 102 waits for the completion of the application module 104 in step 598.
  • the startup module 102 determines whether or not the action can be performed in parallel with additional actions. That is, the startup module 102 determines whether or not it is necessary to delay the execution of any additional action until the completion of the present action. If the action can be performed in parallel with other actions then the procedure returns to step 582 immediately. Otherwise, the procedure waits in step 5102 for the completion of the action, before returning to step 582.
  • Figures 6-12 illustrate exemplary operations of the database manager 108 in Figure 1.
  • the object databases 116, 117, 118 are used to store JavaTM objects.
  • the database manager 108 manages the databases 116, 117, 118 by adding, deleting, or changing objects stored therein as required.
  • the database used in the present invention is designed to be less complex than conventional relational databases. That is, instead of forcing data from an application into relational rows, objects are stored as created, and placed into tables. This efficiency allows for the fast and easy operation of the database as well as its portability with multiple application modules 104.
  • the less complex and faster database of the present invention uses less resources than a conventional database, thereby providing more available resources for the application modules. Since typical personal computers have limited resources available to run JavaTM applications, the efficiency of the database of the present invention allows for sophisticated data access in the low resource environment of a personal computer.
  • Exemplary functions of the database manager which operates on the database include the ability to insert an object into the database, the ability to change (or replace) an object in the database, the ability to retrieve objects from the database, and the ability to delete objects from the database.
  • the format of the database particularly the use of tables, objects, and object IDs within those tables, facilitate the use and speed of the browser, applications which run or the browser, and the database.
  • the format of the database allows the browser to be dynamic. That is, for example, since objects in the database can be easily added, modified, and removed, applications (or content for the applications) can be added, deleted, or modified seamlessly.
  • the browser itself can be modified by simply adding, modifying, or deleting objects from tables within a database.
  • the format of the database allows for efficient and easy software development by allowing programmers to place objects into the database in their original JavaTM form (without having to convert the objects to forms compatible with conventional databases such as breaking the objects into numerous differently typed rows).
  • changes made to the database are first made temporarily in memory, and then are made on disk. This provides the ability to restore the database state in the event of an error.
  • the procedure used to make changes to the databases 116, 117, 118 permanent is called commit.
  • the procedure used to reverse changes made to the databases 116, 117, 118 before making them permanent is called rollback.
  • a further function of the database manager is the ability to modify, delete, or retrieve objects in a database based on a condition. For example, a user or application may wish to delete all objects in a database that are older than a predetermined date. In addition, it may be desirable to modify or retrieve all objects which contain a specific field having a specific value.
  • the delete, modify, and retrieve by condition functions are useful when the identity of the object is not readily available to the application or user at the time the decision is made to modify or delete the object or set of objects. An exemplary embodiment of implementations of these feature are described more fully below.
  • Figure 6A illustrates one embodiment of the insert object functionality of the database 116-118 and database manager 108 according to the present invention.
  • a command is sent to the object database manager 108 indicating that an object is to be inserted into a particular table of a particular database (e.g. , the database corresponding to the application module running at the time the command is set).
  • a unique object ID is created which identifies the object to be inserted. After the object ID is created, the object ID is inserted into the object.
  • object IDs are assigned sequentially such that the first object placed into the database is given the ID of 1. This object ID is incremented by one for each new object inserted into the database.
  • each object will have a unique ID since once an object ID is assigne to an object, that object ID is never used for another object in the same database again.
  • a lock is necessary whenever a user or application wishes to save a retrieved object in the database. For example, two applications (or processes) running at the same time may try to modify the same object at the same time.
  • step 6206 the database manager 108 evaluates a flag contained in the table 119 which identifies whether or not a lock is required to be placed on an object of the table to prevent simultaneous access to objects of the table.
  • step 6208 the object is locked. If a lock is not required or after the completion of the locking step (i.e. , the object successfully locked), the object database manager 108 verifies that the object to be inserted into the table matches the correct object type in step 6210. Each table has a flag which indicates the class (or type) of object that is allowed to be inserted into the table. As noted above, the type is defined as, for example, the structure, fields, and functionality contained in the object. If the object type does not match, the insert fails in step 6212, the insert object procedure is cancelled and an error message is generated.
  • the object database manager 108 determines if the table is set to perform backups. Backups are defined as storing data representing previous versions of tables to prevent corruption of the data. If backups are to be performed for this table, then the backup procedure is begun in step 6218 in which the table is copied into a backup file. After the backup procedure, or if the table is not set for backups to be performed, the object is then written to disk or other recordable media such as a hard drive, an optical drive, a virtual drive, or any other media which can be used to store and retrieve data at step 6216. After step 6216, the object is indexed according to the available indices of the table at step 6220.
  • Backups are defined as storing data representing previous versions of tables to prevent corruption of the data. If backups are to be performed for this table, then the backup procedure is begun in step 6218 in which the table is copied into a backup file. After the backup procedure, or if the table is not set for backups to be performed, the object is then written to disk or other recordable media such
  • the object database manager 108 will index the new object in the "last name" index of the table. This allows a user to locate the object by instructing the database manager 108 to search for the last name field in the appropriate last name index which would then identify the object ID which is stored in the table.
  • the object database manager 108 checks to see if there are any more indices for the particular table in step 6222. If so, then the object is indexed for that particular index in step 6220. This procedure repeats for each index. When all indices have been updated with the new object, the insert object procedure is completed in step 6224.
  • Figures 19A-19C illustrate an exemplary embodiment of the write to disk step 6216 of Figure 6A.
  • an object is written to a random access file by first extracting the object ID from the object in step 19963.
  • the object ID and the object itself are sent to the object database manager 108 so that the object database manager 108 can verify that the object ID does not already exist in the designated database in step 19964.
  • step 19965 it is determined if the object ID is unique. If so, in step 19966, an entry is created in the table file map for the table associated with the object. If the object ID is not unique, then an error is reported in step 19990 and the insert fails.
  • the functionality of the database manager 108 and the databases 116, 117, 118 include the ability to make changes to the databases temporarily and/or permanently.
  • a buffer is used to store a subsection of the contents of the random access file in memory temporarily.
  • the object is stored in memory in its appropriate location in the buffer, and once the contents are verified as being accurate, the contents of the buffer are then stored in the random access file replacing its existing contents, if any.
  • all changes to the random access file are made at one time from the buffer in the commit process.
  • objects are written directly to the random access file without storing them first in the buffer.
  • buffers not only ensures the reliability of the writing procedure, but they also can speed up the access time required to retrieve items from the random access file.
  • another type of buffering provides the advantage of fast access of any object. That is, for example, retrieving an object can be anticipated by the application module 104 prior to the actual retrieving and it can be placed in the buffer.
  • the changes made to the buffer are stored in a memory as a transaction vector, so that each of the changes to made to a table can be reversed, if necessary, before committing them.
  • Figure 19B illustrates an exemplary embodiment of the create a file map entry for the object step 19966 of Figure 19A.
  • an array of bytes is created from the object (e.g. , by using conventional JavaTM serialization techniques).
  • the byte length or size of the array is calculated.
  • a start pointer is assigned which represents the file index for the first byte of free space in the random access file large enough to accommodate the array of bytes.
  • the pointer value determined in step 19976 is stored in the file map.
  • the pointer value stored in step 19977 is marked as an "insert" pointer in the file map.
  • the change to the file map is logged in the transaction vector.
  • Figure 19C illustrates an exemplary embodiment of the insert object into the buffer (step 19967 of Figure 19A).
  • the object is serialized into an array of bytes.
  • a start pointer for the object is retrieved from the file map by evaluating the available free space.
  • the buffer is traversed to the appropriate pointer value where the new object will be stored.
  • the object is stored in the buffer and then after a commit is called, in the random access file.
  • the buffer after a commit, it is determined if the buffer currently in memory is the buffer that was just modified. If so, then in step 19973, the buffer is removed (or restored) from the random access file to keep the contents of the buffer current.
  • FIG. 6B illustrates an exemplary embodiment of the indexing step 6220 of Figure 6A.
  • an index procedure is performed which uses the object and the object ID in step 6228 for each index 120, 121 in the table 119.
  • the index routine 6220 is called to insert an entry into one of the indices associated with a table in a database and the parameters passed to that routine include the object and the object ID, which are to be indexed.
  • a method or procedure (stored or referenced in the index file) is performed on the object to obtain an index value at step 6230. This index value corresponds with the value used by the index to sort the objects of the table.
  • the index may sort on the index value of the last name field of an object.
  • the index may sort on the date of creation of the object.
  • an index may be created for any of the parameters or fields within or relating to the object.
  • a search is performed on the existing contents of the index to determine if the index value is already present in the index.
  • the search may be done by any appropriate method, for example, a binary search may be used. If the index value is already present in step 6232, the new object ID is inserted next to the already existing object IDs that correspond(s) to the index value in the index in step 6234. Otherwise in step 6236, a new index value is created and the object ID which corresponds to the new index value is placed in the list. The procedure ends with step 6238.
  • Figure 7A illustrates an exemplary modify procedure performed by the database manager 108.
  • the object database manager 108 To modify an object, that is, modifying an existing object by replacing it with a changed object, the object database manager 108 must first verify that a lock can be placed on the object to be replaced (or modified) by the action requesting the modify procedure in step 7240 to avoid another request to modify that object at the same time. If a lock cannot be placed on the object, then the modify fails in step 7242. This may occur, for example, if a lock is already placed on that object, indicating that it is currently being changed by another request. If, however, a lock can be placed on the object, then the object is locked by setting a flag associated with that object at step 7243, and the old object is retrieved in step 7244.
  • step 7246 This is performed by asking the table to return the object with a specific object ID.
  • the table uses the file map to determine the physical location of the requested object. Since the modify procedure is modifying an existing object, the specific object ID is known to the application requesting the modification.
  • each index is updated to reflect the change of objects. For example, if there was a change in the last name field, the comparison of the old object with the new object would reflect that the last name has changed. In this case, the index would be updated to reflect the new index value for the modified object.
  • the object ID remains the same.
  • Step 7248 repeats step 7246 for each index for the table. Once all of the indices have been updated, the update procedure is completed in step 7250. Step 7246 will be explained further with respect to Figure 7B.
  • step 7246 will be explained further with respect to Figure 7B.
  • the index value that is, the value according to which the index sorts the objects
  • the index value of the old object is extracted.
  • the old value and the new value are compared and if the index values are the same in step 7258, then the index is still current and it is not necessary to change the index and the procedure ends in step 7260. If the old index value and the new index value are not the same then, in step 7262, the object ID is removed from the index. If the object ID removed was the only object ID which corresponds to that specific index value, the index value is also removed from the index.
  • the new index value is inserted into the index if the new index value does not already exist, along with the object ID.
  • the object ID is inserted.
  • the index is now updated and the procedure ends at 7266.
  • An exemplary embodiment of this feature is illustrated in Figure 8.
  • step 8300 the value of the condition is evaluated and a list of objects which satisfy the condition is returned.
  • the object database manager 108 determines if there are locks or whether locks can be established on all of the objects that have been identified that match the condition.
  • step 8304 If locks cannot be established on all of the identified objects, then the modify procedure fails, an error message is generated at step 8304, and the routine ends in step 8316. If, however, locks can be established then in step 8306, it is determined whether or not the user or application intended on replacing multiple objects. This intent can be communicated to the object database manager 108 via a variable or flag which is sent to the object database manager 108 when the modify procedure has begun. If the flag indicates that the application did not intend for the modify by condition to result in the updating of multiple objects, then in step 8308, the object database manager 108 determines whether or not multiple objects were returned from step 8300. If it is determined that multiple objects were returned in step 8308, then in step 8310, an error message is generated and the procedure ends.
  • step 8308 determines whether or not there are any additional object IDs in the list provided by step 8308 . If, however, it is determined at step 8308 that only a single object was returned in step 8300, or if it is determined at step 8306 that the flag indicates that the user or application intended for multiple objects to be replaced, then the database manager 108 proceeds to step 8312.
  • the first object is modified by the associated object ID, using the procedure shown in Figure 7B.
  • step 8314 when the updating of the first object is complete, i.e. , the modify by object ID procedure ends at step 7266, in step 8314, the object database manager 108 determines whether or not there are any additional object IDs in the list provided by step 8314.
  • step 8300 the object database manager 108 modifies the object corresponding to the next object ID in the list in step 8312 again using the modify by object ID procedure.
  • the procedure ends in step 8316.
  • To retrieve an object having particular characteristics or values from a database it is necessary to query a table with a condition so that the object database manager 108 can return the object IDs of the objects which match the query.
  • An exemplary embodiment of this procedure is illustrated in Figure 9.
  • the query is sent to the object database manager 108.
  • the query can be created by the user using the application or by an application itself.
  • the query can be a boolean expression that returns a true or false, or the query can be an expression which returns a set of results.
  • the query can specify that any or all databases 116, 117, 118, or any or all tables in any or all of the databases are to be searched for objects matching the query.
  • the object IDs of all of the objects which match the query from the table are returned.
  • the various indices associated with each table to be searched can be used to find the object IDs of the objects that meet the criteria presented in the query.
  • the object database manager 108 determines whether or not it is necessary to establish a lock on the returned objects, based on a flag which is stored in the retrieved objects.
  • each table includes a list of locked Object IDs which is referenced by the object database manager 108.
  • FIGS. 18A-18D illustrate an exemplary embodiment of the retrieving object IDs of all of the objects which match the condition in the query in step 9402 of Figure 9.
  • step 18900 all object IDs are retrieved from the file map for the specified table.
  • the query condition is evaluated in step 18902 and the clause evaluator returns the value of the condition (e.g. , a set of object IDs or a boolean value).
  • the procedure ends in step 18906.
  • Figure 18B illustrates an exemplary embodiment of the evaluate condition step 18902 of Figure 18A.
  • a condition descriptor is created.
  • the condition descriptor includes an operations vector which sorts and stores the logical operations (e.g. , boolean operators) of the condition by precedence (e.g. , following an order of operations).
  • the condition descriptor includes a clause map.
  • the clause map associates clause tags (i.e. , a unique identifier which identifies each clause inside of a multiple condition, for example "AU people greater than 10 years old" AND “All people with brown hair” would be represented as A AND B, where A and B are clause tags) with actual clauses.
  • step 18910 the logical operations (in order of precedence) are retrieved.
  • step 18912 the clause map is retrieved.
  • step 18914 the top logical operation is retrieved.
  • step 18916 the logical operation is evaluated to determine if it is unary (e.g. , NOT) or binary (e.g. , AND or OR). If it is unary, in step 18918, the first clause tag is retrieved.
  • step 18920 the clause is evaluated returning a boolean value or a set of object IDs.
  • step 18922 the unary logical operator is retrieved and in step 18924, the clause and operator are evaluated together.
  • the result of step 18924 is stored in a stack called SetMap in step 18926.
  • the presence of additional logical operators is checked in step 18940. If there are no remaining logical operators then in step 18942, the value in the SetMap is retrieved and the procedure ends in step 18944.
  • step 18916 If it is determined in step 18916, that the logical operator is a binary operator (e.g. , AND or OR), then the first clause tag is retrieved in step 18928.
  • step 18930 the clause is evaluated and in step 18932, the next clause tag is retrieved.
  • step 18934 the clause associated with the next clause tag is evaluated and in step 18936 the binary logical operator is retrieved.
  • step 18938 the binary operation is evaluated using the results of step 18930 and step 18934 with the operator retrieved in step 18936.
  • the result of step 18938 is stored in the SetMap in step 18926 and the procedure continues to step 18940 as described above. If, in step 18940, it is determined that there are more logical operators in the operations vector, then the procedure returns to step 18914.
  • Figure 18C illustrates an exemplary embodiment of the create a condition descriptor step 18908 of Figure 18B.
  • step 18942 it is determined if the condition has more than zero operations. If the condition does not include more than zero operations, then the clause is extracted from the condition, assigned a unique ID, and added to the clause map in step 18944. If the condition does include more than zero operations, then the top operator is retrieved from the operation vector in step 18946.
  • step 18948 a determination is made if the operator is a binary operator. If the operator is not a binary operator (i.e. , a unary operator), then the operator is added to the operation vector in step 18950.
  • step 18952 a condition descriptor is created for the second condition of the binary operator by using the above procedure of Figure 18C to recursively create condition descriptors.
  • step 18954 the clause is placed in the clause map and in step 18956, the operator is placed in the operation vector.
  • Figure 18D illustrates an exemplary embodiment of the evaluate clause step 18930 (also steps 18920 and 18934).
  • step 18958 it is determined whether or not the clause has already been evaluated and stored in the SetMap by a previous evaluation step. If so, then in step 18960, the value of clause stored in the SetMap is returned. If the clause has not already been evaluated, then in step 18962, the clause is evaluated by comparing the condition of the clause (e.g. , all people older than 10) with the entries of a corresponding indices for an appropriate table (e.g. , an age index table for a person object).
  • an appropriate table e.g. , an age index table for a person object.
  • Figure 10 illustrates an exemplary embodiment of a procedure for deleting an object by its object ID.
  • a lock is placed on the specified object to be deleted.
  • the object database manager 108 determines whether or not a lock was successfully placed on the identified object. If the lock was not successfully obtained, the delete fails, an error message is generated at step 10506 and the procedure ends at step 10508. If a lock was successfully placed on the object, then in step 10512, the object ID is extracted from the object. In step 10514 and step 10516, the object ID is deleted from each of the indices. If there is more than one object ID associated with an index value for the object in the index, only that object ID is deleted from the index.
  • Step 10514 is described below with respect to Figure 12.
  • the object is deleted from the database in which it is stored in the random access file and the procedure ends at step 10520.
  • step 10518 once an object is deleted from a table and the indices are changed to reflect the removal of the object, it is necessary to delete the object from the file map and allocate its location in the random access file as free space.
  • the file offset is obtained for the object ID from file map.
  • the file map is then modified to indicate that the sectors or byte locations that were previously assigned to storing the deleted object are now available sectors or byte locations. This can be accomplished, for example, by designating the sectors previously assigned to the object in a separate heading in the file map as free space.
  • Figure 19D illustrates an exemplary embodiment of the delete from file map step 10518 of Figure 10.
  • step 19981 it is determined if the table has an object with the specified ID. If not, then an error message is returned in step 19982.
  • step 19983 the file map for the table containing the specified object is retrieved.
  • step 19984 it is determined if the file map contains a file offset (or pointer) corresponding to the object ID of the specified object. If no file offset can be found, then in step 19989, an error message is returned and the delete procedure is aborted. If a corresponding offset is found, then in step 19985, the file offset is returned.
  • step 19986 the disk map entry for the object is removed and the space used in the random access file is indicated in the file map as free space.
  • step 19987 a log of the changes made to the indices in step 10514 of Figure 10 is stored in the transaction vector.
  • Figure 1 1 illustrates the procedure performed by the object database manager 108 for deleting an object based on a condition.
  • the procedure illustrated in Figure 9 is used to return a list of objects which match a specific condition at step 11520.
  • the object database manager 108 verifies that locks have been placed on all of the objects returned by the condition. If locks cannot be established on any of the listed objects, in step 11524, the delete object by condition fails and an error message is produced and the procedure ends. If, however, locks can be established on all of the listed objects, then in steps
  • each of the objects are deleted by object ID, using the routine illustrated in Figure 10, until there are no more object IDs in the list of matches from the condition.
  • This procedure ends at step 1 1530.
  • an exemplary embodiment of a procedure for deleting an object from an index called at step 10514 in Figure 10 is illustrated.
  • a file offset from the file map for the deleted object is determined.
  • a search for example a binary search, on the index is performed to find the first index row which contains the index value.
  • step 12540 If, in step 12536, an index is found which matches the index value, then in step 12540, the object ID is removed from the index. In addition, if after removing the object IDs from the index, there are no additional object IDs which are associated with the particular index value at step 12542, then the index value is also removed from the index at step 12544 and the procedure ends as step 12546. If there are additional object IDs, the procedure ends at step 12546 without deleting the index row. If a match was not found in step 12536, the delete operation fails because the object is not currently in the table, an error message is generated at step 15238, and the procedure ends in step 12546.
  • Figures 13-14 illustrate an exemplary embodiment of the mechanism by which one computer sends data to another computer to which it is connected according to the present invention.
  • This procedure is used, for example, to download new objects which are associated with an application module, from a network computer 100 to one or more client computers 101.
  • the procedure can also be used to pass data files or objects between the network computer 100 and one or more client computers 101 , or between two or more client computers.
  • the updating procedure of Figure 14, which is part of the update procedure 230 of Figures 2 and 3 will run in the background when the client computer 101 first logs on to the network.
  • the user running an application module can trigger an update by which information is transferred to a remote computer (either the network computer 100 or another client computer 101).
  • an update may be triggered by a timer by requiring the client computer 101 to connect with a network computer 100 if a predetermined amount of time has passed (e.g. , after five days) without a connection.
  • each transport cell list 13552 includes, for example, a unique host name identification 13560, a unique (to the sending computer) transport cell identification number, and at least one transport cell (13564 or 13566).
  • Each transport cell 13564, 13566 includes a string of one or more bytes 13568 which represent, for example, an object, a class file, a byte handler, or other data and a content type field 13570 which indicates the type of bytes, for example, whether the bytes represent a class file, an object, a byte handler, or any other data.
  • the outgoing table is stored in the database and is accessed by the database gateway 112 when the update procedure of Figure 14 is running.
  • incoming table 13551 Once data has been transferred to a remote site, it is stored in an incoming table 13551 at the remote computer.
  • the browser running at the remote computer creates an incoming table 13551 which includes at least one transport cell list 13553 containing the identical content of the received transport cell list 13552.
  • the local computer and the remote computer stores a history table 13554.
  • This history table 13554 stores the hostname 13560 (in column 13556) where the transport cell list originated and the transport cell list identification 13562 (in column 13558) for each transport cell list appearing in each incoming table 13551 received from another computer.
  • the browser Upon completion of the update procedure, the browser then evaluates each of the transport cells 13564, 13566 in each transport cell list 13553 stored in the incoming table and where appropriate installs the bytes 13568 on the remote computer using byte handlers based on the value of the content type field 13570. This is described more fully below with respect to Figure 14.
  • FIG 14 is a flow chart of an exemplary operation of step 350 of Figure 3 which performs the updating of the computer using the tables of Figures 13A-13D.
  • a connection to a remote computer is initiated by the local computer.
  • the location of the remote computer e.g. , the IP address
  • the location of the remote computer can be stored in the global settings module 106 or alternatively can be entered by an application or a user.
  • the communication protocol is negotiated between the local and remote computer and an optional authentication procedure is commenced. Examples of different protocols include an "update” service, a "request application module” service, a "status check” service, or a secure "commerce” service.
  • Authentication can include sending a username and password and/or a hostname of the local computer to the remote computer.
  • the remote computer sends an acknowledgment of a successful or unsuccessful authentication. If authentication is not successful, the procedure is terminated in step 14576. If authentication is successful, then in step 14578, the transport cell list identifications associated with the local computer's hostname in the remote computer's history file table are sent to the local computer.
  • the local computer compares the received transport cell list identifications with the transport cell list identification fields of each of its transport cell lists in its outgoing table. After the comparison, in step 14582, the local computer sends all transport cell lists which do not match a transport cell list identification received from the remote computer.
  • the remote computer stores each of the transport cell lists in the remote computer's incoming table and logs the hostname and transport cell list identification fields in its history table.
  • the local computer sends the transport cell list identifications associated with the hostname of the remote computer. This process is now reversed so that the remote computer can send data to the local computer.
  • the remote computer compares received transport cell list identifications from the local computer and compares them with the transport cell list identifications in the remote computer's outgoing table. After the comparison, in step 14588, the remote computer sends all transport cell lists which do not match the received transport cell list identifications from the local computer.
  • the local computer stores each of the transport cell lists in the local computer's incoming table and logs the hostname and transport cell list identification fields in its history table. The update process is then completed in step 14590.
  • both the local and remote computers can additionally set flags for each of the transport cell lists in their outgoing tables to designate specific destinations. For example, if the user of a local computer purchases a new application module (or part of a module), from a remote computer, the remote computer can set a flag in the transport cell list which will designate the local computer as an authorized recipient of the application module contained in the transport cell list.
  • the flag can also represent a boolean expression (e.g. , a condition) to be evaluated to determine whether or not the transport cell list should be sent to the local computer. If the flag is not set, or the expression evaluates to false, the transport cell list will not be sent.
  • the entire contents of the history list is exchanged between the local and remote computers.
  • a remote computer may decide not to send a transport cell list if a predetermined transport cell list (identified by its identification field and hostname field) was already received by the local computer from another remote computer.
  • a predetermined transport cell list identified by its identification field and hostname field
  • Figures 15A-15C illustrate an exemplary installation procedure of the present invention.
  • a byte handler is used.
  • the handler manager 109 is part of the object database manager 108.
  • the handler manager 109 is a separate module which interfaces with both the database gateway 112 and the update module 110.
  • the byte handlers can be stored as objects in the databases 116, 117, 118, and are used by the handler manager 109 to apply the appropriate installation procedure for each possible content type 13570.
  • step 15600 the handler manager 109 is activated.
  • step 15602 a list identifying all transport cell lists in the incoming table 13551 is retrieved by the handler manager 109 from the incoming table 13551.
  • the first transport cell list 13552 is then retrieved by the handler manager 109 in step 15604.
  • steps 15606 and 15608 the first transport cell 13564 of the first transport cell list 13552 is retrieved by the handler manager.
  • step 15610 the handler manager 109 determines if there are any additional transport cells in the first transport cell list. If so, the procedure returns to step 15606 and retrieves the next transport cell. If not, the handler manager 109 determines if there are any additional transport cell lists. If so, then the procedure returns to step 15604 and retrieves the next transport cell list. If not, then the handler manager 109 installs each of the transport cells in step 15614, which is described below with reference to Figure 15C.
  • Figure 15B illustrates one embodiment of the process of step 15608 of Figure 15 A in greater detail.
  • a purpose of the process shown in Figure 15B is to separate transport cells of different content types so that classes can be installed first, byte handlers can be installed second, and all other content types can be installed in order of a predetermined priority.
  • This procedure allows the present invention to avoid attempting to install a JavaTM object before its appropriate class file has been installed. Similarly, this procedure allows the present invention to avoid trying to install bytes of a new content type before the corresponding byte handler has been installed.
  • the handler manager 109 checks the content type field 13570 to determine if it is of type "CLASS" (i.e. , a JavaTM class file).
  • step 15618 the handler manager 109 adds the transport cell to an uninstalled class transport cell list in memory or in the database. Otherwise, in step 15620, the handler manager 109 checks the content type field 13570 to determine if it is of type "HANDLER" (i.e. , a byte handler). If so, in step 15622, the handler manager 109 adds the transport cell to an uninstalled handler transport cell list in memory or in the database. Otherwise, in step 15624, the handler manager 109 checks the content type field 13570 to determine if it is of any type used by any previous transport cell during the entire installation procedure of Figure 15A.
  • HANDLER i.e. , a byte handler
  • step 15628 the handler manager 109 adds the transport cell to an uninstalled transport cell list in memory or in the database corresponding to the known type. Otherwise, in step 15626, a new uninstalled transport cell list in memory or in the database is created corresponding to the type.
  • FIG. 15C illustrates an exemplary embodiment of step 15614 of Figure 15A.
  • the handler manager 109 references byte handlers which inform the handler manager how to install bytes of their respective content type.
  • the handler manager 109 determines if there are any transport cells in the uninstalled class transport cell list. If so, in step 15634, the first transport cell is retrieved.
  • the "class" byte handler is retrieved and the "class" byte handler installs the class file contained in the bytes field of the transport cell.
  • step 15630 the handler manager 109 determines if there are any transport cells in the uninstalled class transport cell list. If so, in step 15634, the first transport cell is retrieved.
  • the "class" byte handler is retrieved and the "class" byte handler installs the class file contained in the bytes field of the transport cell.
  • the handler manager 109 determines if there are any more transport cells in the uninstalled class transport cell list in memory or in the database. If so, the procedure is returned to step 15634 for the next transport cell. If there are no transport cells in the uninstalled class transport list (i.e. , the result of step 15630 is no), or if there are no more transport cells in the uninstalled class transport cell list at step 15642, then in step 15632, the handler manager 109 determines if there are any transport cells in the uninstalled byte handler transport cell list. If so, in step 15636, the first transport cell is retrieved.
  • step 15640 the "byte handler" byte handler is retrieved and the "byte handler" byte handler installs the new byte handler file contained in the bytes field of the transport cell.
  • step 15644 the handler manager 109 determines if there are any more transport cells in the uninstalled byte handler transport cell list. If so, the procedure is returned to step 15636 for the next transport cell.
  • step 15646 the handler manager 109 sorts the remaining byte handlers by priority.
  • the priority of a byte handler is contained in a flag which is received by the handler manager 109 as part of the byte handler. After sorting, the byte handler with the highest priority is retrieved in step 15648.
  • step 15650 all transport cells from the uninstalled transport cell list corresponding to the selected byte handler are retrieved.
  • step 15652 the first transport cell is retrieved and in step 15654, the corresponding byte handler is retrieved and installs the bytes contained in the bytes field of the transport cell.
  • step 15656 the handler manager 109 determines if there are any more transport cells in the corresponding uninstalled transport cell list. If so, the procedure is returned to step 15652 for the next transport cell. If the result of step 15656 is no then, in step 15658, the handler manager 109 determines if there any additional byte handlers from steps 15646 and 15648. If so, then the next byte handler is retrieved in step 15648. Otherwise, the procedure ends in step 15660. If installation of all bytes was successful, the handler manager 109 calls a commit procedure to make the installation permanent.
  • FIGS. 16A-16C illustrate exemplary structures of an application module
  • application module 104 includes at least one mode which typically includes a model 16702, a view 16704, and a controller 16706.
  • a series of modes 16700, 16710, 16712 can be linked in a group 16708.
  • modes 16700, 16710, 16712. in a group 16708 any of the models, views, or controllers of any of the linked modes 16700, 16710, 16712 can be shared or transferred from one mode to another.
  • a group 16714 can include a combination of modes 16700, 16718, 16720, 16722 and groups 16716 in series, thereby sharing model, view, and controllers between modes of different groups.
  • Figures 17A-17J illustrate an exemplary interactive educational system application module of the present invention.
  • the exemplary interactive education system enables users to receive educational courses and other related information at the user's personal computer via updates received over a network (e.g. , the Internet, a direct-to-server dial-in, or from a Intranet or Web site).
  • the updates occur automatically each time the user runs the application while connected to the network.
  • the user is provided an individualized educational portfolio that provides the user with faster, better information, and provides administrators immediate feedback on a user's needs and progress.
  • the application module includes a display 17800 having a profile button 17802, a library button 17804, a course button 17806, a notes button 17808, a glossary button 17810, a flashcard button 17812, a post-test button 17814, a final exam button 17816, a score button, 17818, a portfolio button 17820, a mailbox button 17822, and a quit application button 17824.
  • a graphic 17826 is displayed which indicates the course presently selected by the user of the application module.
  • the update procedure is performed during the startup module 102 if a network connection is available. If a network connection is not available, then the update procedure can be delayed for the next time the startup module 102 is activated.
  • the startup module 102 or the application module 104 can monitor the client for the presence of a network connection and prompt for an update once a connection is detected.
  • the startup module 102 or the application module 104 can initiate an update procedure at any time.
  • the view changes to Figure 17B allowing the user to enter his/her personal information in a profile/registration box 17828.
  • the user activates the end profile button 17830 and the personal information is stored and placed in the outgoing table 13550 of the client computer to send to the educational server during the next update 230 of the system.
  • the view changes to Figure 17C allowing the user to select the course from a course window 17830.
  • a description of the selected course is displayed in a description window 17832 and the course selection is made final by activating the select course button 17834. If the user does not wish to select a course, the user can activate the cancel button 17836 returning the user to Figure 17A.
  • notes button 17808 When the user activates the notes button 17808, the view changes to Figure 17D allowing the user to view notes in a note window 17838. When the user is finished viewing his/her notes, the user activates the end notes button 17840 to return to Figure 17A.
  • notes can be entered in a note window available from an "enter notes" button located on any window where the user may desire to take notes (e.g. , while viewing course material or flashcards).
  • the view changes to Figure 17E allowing a user to scroll through a list of glossary terms in the glossary window 17842.
  • the user can search the terms of the glossary by entering a search term in the search window 17844.
  • the user can activate the end glossary button 17846 and return to Figure 17A.
  • the view changes to Figure 17F allowing a user to select a flashcard 17848 with a term using the previous button 17850 and the next button 17852.
  • the user can switch between a display of the term or its definition by activating the term button 17856 or definition button 17854, respectively.
  • the user can activate the end flashcard button 17858 and return to Figure 17 A.
  • the user can activate the post-test button 17814 which changes the view to Figure 17G and administers a practice test of the chapter material. Questions are asked in the question window 17860 and can be traversed using previous button 17866 and next button 17868. The user enters his/her answers in answer box 17862 by selecting one of the answer buttons 17864. In an alternative embodiment of the present invention, the user types short answers in response to questions.
  • New question and answer formats can be added to the application module by taking advantage of the updating procedure of the present invention. The new question format would be received in a transport cell and the handler manager 109 would install new objects which would change one or all of the model, view, and controller of the application module.
  • the user can activate the end test button 17870 and return to Figure 17A.
  • the results of the post-test can be placed in a transport cell in a transport cell list in the outgoing table 13550 of the local computer to be sent to the server for evaluation as well as other statistical information such as the length of time spent on certain questions.
  • the server (or administrator) can also evaluate the responses to questions of many clients in order to determine if a particular question is flawed.
  • the server can then send an update to all of the clients in order to replace the flawed question with a new question by placing the new question in its outgoing table.
  • the user can activate the final exam button 17816 (preferably after completion of all of the chapters of a course) which changes the view to Figure 17H.
  • Questions are asked in the question window 17872 and can be traversed using previous button 17880 and next button 17882.
  • the user enters his/her answers in answer box 17874 by selecting one of the answer buttons 17876 during a predetermined time period displayed by a clock icon 17878.
  • the user can activate the end test button 17886 and return to Figure 17A.
  • the user can select the quit button 17884 to quit the final exam without saving the results.
  • the results of the final exam can be sent to the server for evaluation as well as other statistical information such as the length of time spent on certain questions.
  • the user can activate the score button 17818 and the view changes to Figure 17H.
  • the user can display the score results in different ways by selecting a display scheme from the display scheme window 17890. Examples of display schemes are score by topic, score by objective (text), and score by objective (graph).
  • the scoring data is displayed in the score window 17888.
  • the user can activate the end score button 17892 and return to Figure 17A.
  • the portfolio button 17820 the view changes to Figure 171.
  • the portfolio window 17894 displays a list of the completed courses by the user.
  • the user can activate the end portfolio button 17896 and return to Figure 17A.
  • the user can also have an electronic mailbox which can be activated by mailbox button 17822.
  • the mailbox feature can have its own display and send mail through the update procedure of the present invention.
  • the user selects the quit button 17824 in Figure 17A.

Abstract

La présente invention concerne un navigateur de recherche dynamique d'applications capable de traiter plusieurs applications et permettant l'échange sans discontinuité d'informations d'un ordinateur à l'autre. Ce navigateur de recherche dynamique d'applications tourne sur un premier ordinateur desservant une base de données conservant en mémoire une pluralité d'objets. Le navigateur comporte également un module de mise à jour qui télécharge des objets d'un second ordinateur et un gestionnaire de base de données. Le gestionnaire de base de données, qui gère le rangement en mémoire et l'accès aux objets rangés dans la base de données considérée, fait l'interface entre le module d'accès et la base de données considérée. La base de données considérée comporte au moins une table permettant de ranger l'un au moins des différents objets.
EP99967210A 1999-12-07 1999-12-07 Navigateur de recherche dynamique d'applications et base de donnees a cet effet Withdrawn EP1266283A4 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US1999/028894 WO2002059741A1 (fr) 1999-12-07 1999-12-07 Navigateur de recherche dynamique d'applications et base de données à cet effet

Publications (2)

Publication Number Publication Date
EP1266283A1 true EP1266283A1 (fr) 2002-12-18
EP1266283A4 EP1266283A4 (fr) 2006-06-21

Family

ID=22274227

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99967210A Withdrawn EP1266283A4 (fr) 1999-12-07 1999-12-07 Navigateur de recherche dynamique d'applications et base de donnees a cet effet

Country Status (4)

Country Link
EP (1) EP1266283A4 (fr)
JP (1) JP2004518215A (fr)
CA (1) CA2397620C (fr)
WO (1) WO2002059741A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0811942A2 (fr) * 1996-06-07 1997-12-10 Cyber Media, Incorporated Mise à jour automatique de produits logiciels divers dans des systèmes ordinateurs à clients multiples
US5845077A (en) * 1995-11-27 1998-12-01 Microsoft Corporation Method and system for identifying and obtaining computer software from a remote computer
WO1999045465A1 (fr) * 1998-03-03 1999-09-10 Siebel Systems, Inc. Procede, systeme, appareil, et produit programme pour repartir et instancier des mises a jour de logiciels
US5960204A (en) * 1996-10-28 1999-09-28 J.D. Edwards World Source Company System and method for installing applications on a computer on an as needed basis
US5974454A (en) * 1997-11-14 1999-10-26 Microsoft Corporation Method and system for installing and updating program module components

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3144022B2 (ja) * 1992-01-22 2001-03-07 富士ゼロックス株式会社 プログラムデータベースシステム
JPH08328929A (ja) * 1995-06-06 1996-12-13 Hitachi Ltd データベース分割管理システム
JPH0916624A (ja) * 1995-06-28 1997-01-17 Hitachi Ltd 階層型データ検索方法
US5892905A (en) * 1996-12-23 1999-04-06 International Business Machines Corporation Computer apparatus and method for providing a common user interface for software applications accessed via the world-wide web
JPH1196187A (ja) * 1997-09-19 1999-04-09 Nec Corp マルチメディアファイルサーバ
JPH11259284A (ja) * 1998-03-12 1999-09-24 Fujitsu Ltd オンラインプログラム更新システム及びプログラム更新用プログラムを記録したコンピュータ読み取り可能な記録媒体

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5845077A (en) * 1995-11-27 1998-12-01 Microsoft Corporation Method and system for identifying and obtaining computer software from a remote computer
EP0811942A2 (fr) * 1996-06-07 1997-12-10 Cyber Media, Incorporated Mise à jour automatique de produits logiciels divers dans des systèmes ordinateurs à clients multiples
US5960204A (en) * 1996-10-28 1999-09-28 J.D. Edwards World Source Company System and method for installing applications on a computer on an as needed basis
US5974454A (en) * 1997-11-14 1999-10-26 Microsoft Corporation Method and system for installing and updating program module components
WO1999045465A1 (fr) * 1998-03-03 1999-09-10 Siebel Systems, Inc. Procede, systeme, appareil, et produit programme pour repartir et instancier des mises a jour de logiciels

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO02059741A1 *

Also Published As

Publication number Publication date
EP1266283A4 (fr) 2006-06-21
WO2002059741A1 (fr) 2002-08-01
CA2397620A1 (fr) 2002-08-01
JP2004518215A (ja) 2004-06-17
CA2397620C (fr) 2009-11-17

Similar Documents

Publication Publication Date Title
US6654748B1 (en) Dynamic application browser and database for use therewith
US7506257B1 (en) System and method for providing help contents for components of a computer system
US7200806B2 (en) System and method for generating pre-populated forms
US6408434B1 (en) System and method for using a substitute directory to automatically install an update program
US6968550B2 (en) Apparatus and method for synchronizing software between computers
US7100115B1 (en) Method and apparatus for providing computer-based help
US7293115B2 (en) Internet-aware agent for automatically updating applications without executing the application
US7607095B2 (en) Method and apparatus for binding user interface objects to application objects
US6421684B1 (en) Persistent volume mount points
US8234620B1 (en) Method and system for software development using distributed computing resources
US20100223325A1 (en) Dynamic generation and automated distribution of user interface from database model
BG64962B1 (bg) Метод и система за селективно дефиниран достъп напотребител до компютърна система
CN101329636A (zh) 虚拟化窗口信息的方法和设备
WO1999004346A1 (fr) Procede et dispositif permettant de maitriser le comportement de systemes de traitement d'applications et ce, sans modifier ces derniers
EP1000402A1 (fr) Interface utilisateur de gestion de groupes de verrouillage
US8185562B2 (en) Business object browser for business query language
US7302477B2 (en) Administration tool for gathering information about systems and applications including the feature of high availability
WO2003058430A1 (fr) Dispositif, procede et article manufacture destines a la synchronisation de donnees entre des applications integrees
US20210117174A1 (en) Providing context-based application suggestions
WO2003104984A2 (fr) Dispositifs de commande et dispositifs de commande auxiliaires produisant des affichages d'interface utilisateur
JP2003131919A (ja) 文書管理装置
US7107290B2 (en) Method and system for automatically checking-out/in and replicating documents in databases
US7047234B2 (en) System and method for managing database access
CA2397620C (fr) Methode et systeme permettant l'echange d'information d'application
EP0950953A2 (fr) Procédé et appareil pour un méchanisme d'édition de propriétés dans un environnement de réseau d'ordinateurs

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020705

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

A4 Supplementary search report drawn up and despatched

Effective date: 20060516

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 9/445 20060101AFI20060511BHEP

17Q First examination report despatched

Effective date: 20060731

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: RWD TECHNOLOGIES, INC.

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: RWD TECHNOLOGIES, LLC

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ANCILE SOLUTIONS, INC.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20121127