GB2364406A

GB2364406A - Multi-user access of a database over a network

Info

Publication number: GB2364406A
Application number: GB0026699A
Authority: GB
Inventors: Graham Kennedy Twaddle
Original assignee: SHERWOOD INTERNAT GROUP Ltd
Current assignee: SHERWOOD INTERNAT GROUP Ltd
Priority date: 1999-11-01
Filing date: 2000-11-01
Publication date: 2002-01-23
Also published as: GB0026699D0; GB9925841D0; WO2001033388A3; EP1436729A2; WO2001033388A2; AU1155301A; ZA200103886B

Abstract

User specific data pages are pre-generated and stored for each user in advance of a receipt from the user of a request for a data page. Static and semi-static pages are stored at the server and transmitted to the user upon request. Dynamic pages, requiring information from a database server, are not pre-stored but are dynamically generated upon request. This improves the accessibility of multi-user databases e.g. Internet based online web databases, by reducing demand for database processing time, this allowing more users to access the database.

Description

2364406 Method and Svstem for Multi-user Access of a Database over a

Network, and Computer-Readable Storage Medium Storing a Program for Performing the Method

5 Technical Field

The present invention relates to information retrieval from a database and in particular to concurrent multi-user informational retrieval. In particular the present invention is of particular application to the extraction of information from a privately held database over a network, and more particularly in a preferred 10 embodiment through the provision of online services through the Internet.

Prior A The problem of multi-user access to a centrally held database or centrally stored applications has a long history. The first systems to provide effective multi-user capability were main frame systems. Here, applications and databases 15 would be centrally stored on the main frame, and multiple dumb terminals would be provided connected to the main frame in order to communicate therewith. In use, a user would log in at the dumb terminal and would then be able to access the applications and database stored on the main frame. Such main frame systems can provide applications with limited search facilities and can deal with very high 20 volumes of OLTP transactions, by using TP monitors such as those known in the art as CICS or TUXEDO. Typically, main frame systems are provided with the capability to serve a maximum of 30,000 users concurrently In use, main frame systems characteristically suppor't simple transactions which are completed in a single screen. Since the communications from 25 the terminals to the main frame are effectively provided by sending screens of data between the two, main frame systems are effectively "stateless", in that the problem of knowing where you are in a transaction when keeping a set of data current is not usually available in the applications. As a result, performing processes which require a "state" to be stored somewhere in the system is not usually feasible on main frame systems, and in particular main frame systems which are required to serve high numbers of users.

5 The next evolution in multiple user access systems was in the form of client server architectures. Here, desk-top computers can store their own applications, but are connected to a central network server which may have further applications and databases stored therein. Client server architectures allow the "state" of a process to be stored in the back end system until either the application gets rid of it or the user 10 closes their connection by logging out.

The ability to store the "state" of a process allows many important process features to be designed. Typically, systems that can store the state of a process are referred to as "state full systems" and these refer to systems where either the user interface or the back end computer system can store the present state of a 15 process, being effectively a pointer into the present or the next process step to be performed. The ability to store the state allows features such as stepping backwards and forwards through lists to be designed, as well as the ability to save the present state of a process to continue processing at. a later time.

In recent years a new medium has become more popular for allowing 20 multi-user access to data in the form of the Internet. Although the Internet has been available to academics for decades, its recent growth in popularity stems mainly from that part known as the World Wide Web (hereafter referred to as "the Web") which provides for user friendly graphical user interfaces (GUls) to provide information.

The Web provides information by making hypertext documents 25 available to users in the form of "pages". A "page" can be considered to be the basic unit of information in use on the Web, and can contain text, graphics, animation, as IP well as input interfaces which allow users to enter information for transmission over the Web. In practice, however, Web based systems are similar to main frames in that they send pages or request pages of information resulting in characteristically simple processes which do not require any storage of the state thereof. Several prior art solutions have been proposed to this problem of the lack of a storage of the state of 5 processes, in the form of application servers and object request brokers (ORBs).

Application servers represent an additional layer provided at the Web server which keeps the state of the application in the middle tier by holding the concept of a "browser session" and sharing the back end database sessions amonast front end sessions. Similarly, object request brokers allow an object or state to be 10 instantiated in the middle tier and shared or made exclusively available to one or more front end browser users. Both of these solutions are effectively trying to provide a state for an application separate from the state of the back end database or system.

As a result, the systems are having to manage the virtual front end user sessions separately from the actual back end sessions resulting in difficulties in scaling the 15 solution to cope with many thousands of concurrent users.

Summary of the Invention

The present invention provides a further solution to the problem of multiple user access to a private database over the Internet, which overcomes the above-described problems of the prior art solutions and allows scalability to provide

20 concurrent access for as many as 100,000 to a 1,000,000 active users. The present invention is of particular application to private databases which do not provide open public access, and can only be accessed by users who have made prearrangements to do so. The high number of concurrent multiple users is achieved in two ways. Firstly, each reuistered user is allocated personal Web pages which only they can access.

25 These Web pages may be personalised to the user and provide as much or as little functionality in the way of, for example, data entry etc. as is required for the user.

Secondly, in addition to providing personalised Web pages, each Web page is treated 4 as one of three ty es, referred to herein as static, semi-static, and dynamic, each Ip I respective type of Web page providing progressively more processing functionalitv.

0 I= and static and semi-static pages having been generated in advance of the time when they are actually requested by a user, The provision of the three different types of 5 Web pages, and in particular of the "semi-static" pages, provides the ability to separate user requests into manageable loads, without having, to provide either all static or all dynamic services.

From one aspect, the present invention provides a method of providing access to a database over a network, comprising the steps of.

10 pre-generating one or more user-specific data pages for a user, one or more of said data pages being further arranged to allow the user to indicate that at least one transaction is to be performed; storina each of said pre-generated user-specific data pages; receiving user requests for the user-specific data pages over the 15 network; and transmitting the requested one or more of the user-specific data pages to the network for transport to the user in response to the received request; wherein said pre-generating and storing steps are performed in advance of the receipt of the user requests for the data pages.

20 From another aspect, the present invention also provides a system for providing access to a database over a network, comprising page generation means for pre-generating one or more user-specific data pages for a user, one or more of said data pages being further arranged to allow the user to indicate that at least one transaction is to be performed; 25 page storage means for storing each of said pre-generated user- specific data pages, pacre request reception means for receiving user requests for the userspecific data pages over the network; and page transmission means for transmitting the requested one or more of the user-specific data pages to the network for transport to the user in response to the received request; 5 wherein said page generation means and said page storage means respectively pre-generate and store the user-specific data pages in advance of the receipt of the user requests for the data pages by the page request reception means.

Furthermore, the present invention also provides a data page generation method for generating user-specific data pages incorporating userspecific data 10 retrieved from a database, comprising the steps of retrieving user-specific data specific to a user from the database; generating a user-specific data page incorporating said user-specific Z_ data, said data page being further arranged to allow the user to indicate that a process is to be performed; and 15 storing the generated user-specific data page; wherein the user-specific data page is generated and stored before it is requested by the user.

Moreover, from a yet further aspect, the present invention also provides a data page generation system for generating user-specific data pages incorporating 20 user-specific data retrieved from a database, comprising the steps of database access means for retrieving user-specific data from the database; page generation means for generating a user-specific data page incorporating said user-specific data, said data page being further arranged to allow 25 the user to indicate that a transaction is to be performed; and page storage means for storing the generated user-specific data page; wherein said page generation means and said page storage means 6 respectively pre--generate and store the user-specific data pages in advance of the receipt of user requests for the data age.

p C, Furthermore, from another aspect, the present invention also provides a system for multi-user database access comprising means for storing userspecific Z__ I,.:, 5 data. means for receivin and processing user requests for data, and data retrieval 9 L-1 means for retrievine, data from a central database in response to user requests, wherein the user-specific data is in the form of at least three data types, one or more of which types may be dynamically updated with data from the central database in response to user requests.

10 From a further corresponding aspect, the present invention provides a method of multiple user data access, comprising storing user-specific data, said user's specific data being of at least three data types; receiving user requests for data from a network; processing the user requests for data to determine the data type requested; retrieving any necessary data requested by the user from a central database; and 15 transmitting the requested data to the user; wherein said retrieving step is performed when the user requests data of one or more of said three types which may be dynamically updated with data from the central database.

From a yet further aspect, the present invention also provides a Web based system for multi-user access to data in an online database, comprising: means 20 for storing Web pages specific to each user; means for processing user requests for Web pages, data retrieval means for retrieving data from the database in response to user requests, and page formatting means for dynamically formatting user specific pre-created Web pages containing the data retrieved from the database, wherein the page transmitted to the user may be dynamically created or retrieved from static 25 storage depending on the user requests.

Furthermore, from yet another aspect, the present invention further provides a Web based method of multi-user access of an online database comprising 7 storing pre-created Web pages specific to each user, processing user requests for Web pages, retrieving data from a database in response to the user requests. if required; dynamically formatting user specific Web pages containing the data retrieved from the database- and transmittina the requested Web page to the user, wherein the 5 transmitted page may be a pre-created Web page or a dynamically created Web page as required.

The pre-generated pages are the static and semi-static pages, and at least some of the pre-generated pages are provided with the ability to allow the user to indicate that a transaction process is to be performed. The pregeneration of the pages 10 together with the ability of the pages to indicate that a process should be performed provides the advantage that on-line transaction processing (OLTP) forms can be provided to the user already pre-populated with user-specific information, and the user can review that information and on the same form indicate whether a transaction process is required. The indicated transaction can be performed on or using the user 15 specific data stored on the particular pre-generated page which the user has used to Cp CI indicate the required transaction.

Preferably, one or more user-specific data pages are pre-created for a plurality of users, one or more of the pages created for each user being, provided with the ability to indicate that at least one transaction is to be performed. The respective 20 created pages are private to each respective user.

In a preferred embodiment, the user desiring to. access the database will use a standard browser which utilises simple hypertext markup language (HTNIL).

Furthermore, a standard Web server is preferably used to deal with incoming request handling, thus providing the advantage that the system can have many Web servers 25 and no particular user is restricted to any particular server.

The present invention provides for storage of the processing state where required, which will typically be when a user makes a request which causes a Web page to be dynamically created. In the preferred embodiment storage of the process state is achieved by saving an indicator or pointer to the state in each user's private Web pages. This allows for the respective states to be stored individually for each user.

5 In the preferred embodiment the user-specific data pages are preferably of three types, referred to herein as static, semi-static and dynamic. Static pages are simple Web pages created for pub.lishing information such as company and product information etc. and are not subject to frequent change. Semi-static pages may be subject to periodic change such as for instance every 24 hours and include pages 10 specifically created and maintained for the user with all of their relevant information up to date on it. In addition, semi-static pages may contain buttons or other means such as drop-down lists to allow the user to indicate that specific transactions, requests or actions should be performed OLTP for the specific user for which the page has been created. For example, where the system is being used in an insurance 15 system, the semi-static page for a particular user with a particular insurance policy may contain an action button to allow the user to make a claim against his policy, the claim beina a transaction. Other transactions may for example be data editing processes.

Dynamic pages are pages created by the system upon demand in 20 response to a user request. Dynamic page creation is well known in the art, but has the distinctive drawback that it is not capable of processing concurrent users numberinc, in the thousands due to the dynamic processing nature of the process.

In the present invention, however, dynamic pages may be created by a process of merging predesigned Web pages with data extracted from the database by 25 appropriate database retrieval means. In order to provide an interface between the Web server using HTNEL and the database, a parser means can be provided to process the user request for dynamic information so as to control the database retrieval means to retrieve the appropriate information from the database. Similarly, once the data has been retrieved, the parser can perform a merge process to merge the retrieved data from the database into the Web page which is then passed to the Web server as HTNEL. In order to provide the merger facilities in the parser, a form of markup 5 lanc, aoe known as extensible markup language ()CAL) can be used, as XNEL can be u t customised as required.

With respect to the semi-static user pages,. the present invention provides that these pages may be updated on a regular basis upon initiation from a refresh event. Refresh events may occur in a number of ways, such as, for example, 10 a timer event programed to run periodically, or from a command from the system administrator, Preferably, the refreshing of the semi-static pages with data from the, central database is performed in a similar manner to creating dynamic pages, utilising the parser and the database retrieval means. In this respect, it will be noted that the process of refreshing the semi-static pages is much like a batch process, and can be 15 performed whenever the load on the system renders it convenient.

With respect to the database retrieval means themselves, preferably these are standardised database controllers such as those sold under the name of Oracle, which uses structured query language (SQL) to access the database.

The method of the present invention may be embodied in a computer 20 program arranged to control a computer loaded with the program to perform the method. The computer program may be stored on any suitable computer readable storaae medium, and in particular, magnetic discs, magneto-optical discs, and optical discs are particularly suitable. In addition, in other embodiments the storage medium may also be a computer memory, which may be random access or read-only, and 25 which may further retain it's contents with or without power.

The present invention has the primary advantage that by providing each user with private access user specific Web pages, and then by further dividing those Web pages into at least three different types, the ability to service multiple users concurrently is increased. In tests of the system to date, as many as 100, 000 individual users have been able to use the system concurrently, although it is envisaged that this number may increase up to as much as 1,000,000. It will therefore 5 be understood that the present invention provides a highly scalable solution to the problem of multiple user access to a database over the Internet.

Brief Description of the Drawings

Further features and advantages of the present invention' will become 10 apparent from a consideration of the following description of a specific embodiment thereof, present by way of example only, and by reference to the accompanying drawings, in which:

Figure I shows a schematic diagram of the overall system architecture of the present invention; 15 Figure 2 shows a flow diagram of the basic steps taken in processing a user request; Tigure 3 shows a flow diagram illustrating the process steps in dynamically creating Web pages; and Figure 4 shows a flow diagram illustrating the process steps in updating 20 semi-static pages.

Description of the Preferred Embodimen

The system architecture of the present invention will now be described with reference to Figure 1.

25 In Figure 1, a user 2 is equipped with a computer arranged to access the Internet using a standard Web browser. When desiring to access the online database, the user can access a Web server 8 by means of the Internet in the usual manner. The I I Web server 8 is arranged to communicate with an application server 10 which together form means for providing the Website 6. The Website in question consists of a number of user specific Web pages 14, each user having their own Web pages which are accessible only by themselves. The provision of private Web pages and the 5 security required to implement them are well known in the art.

Each page of each set of user specific Web pages 14 is divided into one of three types, being static pages 16, semi-static pages 18, and dynamic pages 20.

Static pages are Web pages created in advance and arranged to contain information which does not need to be updated frequently such as information regarding company 10 contact details, product information, etc. etc. These static pages are provided on the Website in the usual manner, and are provided to the user from the Web server upon request in the usual way.

Semi-static pages are Web pages which contain information which must be updated regularly or periodically such as, for example, on a nightly basis. These 15 pages are specifically created and maintained for the user in advance and contain all of their relevant personal information. Furthermore the pages can contain action buttons or other means such as drop-down menus to allow specific requests and actions to be performed OLTP for the specific user on the information shown on the specific page. For example, where the system is being used for online insurance 20 purposes, a specific user's semi-static page may relate to their own insurance policy and contain all of the policy details. Action buttons can be provided on the page to allow the user to perform various actions on the policy, such as for instance make a claim against the policy.

The third type of page are dynamic pages and these are created 25 dynamically by the back end system 100 to be described later for specific user requests. Many prior art systems provide dynamic page creation, and the use of dynamic pages is well known.

The application server 10 is arranged to communicate with the back end system 100 which comprises a parser means 34 provided with an associated file system 3 8, the parser means being arranged to communicate with a database access Z:

32 which accesses the central database 50, For example, when used in an means 1 5 insurance application, the central database 50 may be the insurance company's central database containina records of all of their policy holders tocrether with the present I CI states of their insurance policies. System administration means 40 can be provided in order to directly access the parser means, the database access means, and the Website in the form of the Web server and application server.

10 The system of the present invention is further provided with one or more computer readable storacre mediums such as ma2netic discs, magnetooptical discs, optical discs, or computer memory for storing a computer program which controls the various system elements to perform the operations required of it by the present invention. The computer program may be stored on a central storage medium 15 such as the file system 38, or relevant modules of the program may be stored distribute between the web server's, application server's, or back-end system's respective computer storage media.

From a consideration of the above-described architecture, it will be apparent that the information in the central database 50 is centrally and collectively 20 stored therein for each and every user, but that at least parts of this information are recreated privately for each user on the respective private user specific Web pages.

In particular, the static and semi-static pages which are created in advance will themselves store some of a particular user's specific data in addition to it being stored in the database. These pages are pre-generated and stored in advance of the user 25 actually requesting any of the pages, and are merely provided directly out of the page C) 1-:1 store when a user finally requests one of the pages. This architecture eliminates the need for the back end system to have to access the data base to service each user request by dividing the information into user-specific Web pages, which are I z:1 themselves static, semi-static pages which are pre-generated and then provided out of a page cache, or dynamically created upon request. It will be apparent that only those pages which are required to be dynamically created in response to a user request will 5 require dynamic access to the database, and thus access to the database for any particular user can be statistically reduced. Thus, the overall number of users which can be serviced is increased.

The process which the system utilises in processing a user request for information is shown in Figure 2. Herein, at step 202 a user uses a computer 10 equipped with a standard Web browser to request information from the respective user specific Web pages. The request is in the form of a universal resource locator (URL) which identifies the Web page required, and is transmitted to the Web server 8 by the Internet 4 at step 204. The Web server 8 analyses the request at step 206 to determine whether the Web page requested is a static page, a semi-static page, or a 15 dynamic page. If it is determined that the requested page is a static page or a semi static page, then the page is merely obtained from the page store (cache) and transmitted from the server to the user at steps 208 or 210 respectively. If it is determined that the requested page is a dynamically created page which requires data to be retrieved from the central database 50, the request is passed to the back end 20 system 100 for processing and page creation. Herein, the request is processed at step 212, the data is obtained from the database at step 214, and the obtained data is merged with the Web page at step 216. Steps 212, 214 and 216 constitute process 300 which is described more fully with reference to Figure 3 later. Once the dynamic Web page has been created, it is then transmitted to the user at step 218.

25 The process for dynamic page creation will now be described with reference to Fiaure 3.

Where a user has made a request for information which requires data 14 to be dynamically extracted from the central database 50, ie. the user has requested a dynamic Web page, the request is passed from the application server 10 to the parser means provided in the back end system at step 3302. The parser examines the URL passed from the application server and obtains the HTNff_ file relating to the URL 5 from the file system 38. The HTNIL file will contain specialist tags and other flags, and in this respect can more properly be considered to be an XNff- file. The user means parses the received HTNIL file at step 3 06 to locate the specialist tags, and for each tag found calls an appropriate database procedure at step 308 by passing instructions to the database access means. The database access means then executes 10 the database procedure to obtain data 'from the central database 50 at step 3 10, and the retrieved data is passed back to the parser at step 3 12. The parser then merges the retrieved data into the HTNff_ file to create the Web page. An evaluation 316 is then performed to determine if the end of the HTNff, file has been reached and if not the parsing and database access procedure is repeated line by line until the end of the 15 HTML file is reached. Once the end of the file has been reached, the file together with the retrieved data merged therein is passed back to the application server and then to the Web server for transmission to the user. In this manner Web pages can be dynamically created containing, information from the central database in response to user requests. This arrangement for dynamically creating the Web pages has the 20 further advantage that the visual layout of the HTNIL file can be specified in advance by specialist marketing and graphic designers, and the data can be simply merged into the file where required. This therefore takes the responsibility for the layout of the pages out of the hands of the specialist database programmers.

The procedure for refreshing semi-static pacres will now be described 25 with reference to Figure 4.

As discussed previously semi-static pages are pages which contain information which must be updated on a regular basis, but which do not need to be dynamically created in response to a specific user request. The updating of these pages is initiated by a refresh event at step 402. Valid refresh events which cause the procedure to be started may be for example timer events which are arranged to run periodically, or may be specifically initiated upon command from the administration 5 system asrequired. In this respect the refreshincr of the semi-static pages can be I'D considered to be the equivalent of a batch process, and therefore has the advantage that the refresh routines can be performed at a time when the load on the system is not high. In addition, it may be possible for some users to initiate refresh events from their Web pages, the ability of each user to do this being dependent upon the 10 particular database services provided to each user. The refresh routine for each semi static page may be slightly different, but will generally follow the outline given below.

Upon initiation of the refresh event at step 402 the central database 50 in the back end system is accessed by the database access means and the necessary data is retrieved therefrom. Any processing which may be required upon the data 15 prior to insertion into the semi-static Web pages can be performed at this point at step 406, and then the results of this processing or the retrieved data can be merged with C) CP the page to update the page. In refreshing each semi-static page it is envisaged that the same method for dynamically creating pages can be used utilising the parser means to parse the page HTNE file for specialist tags, and then using the found tags 20 to control the database access means to retrieve the necessary data from the central database. The retrieved data is then merged in to the pre-prepared HTNIL form, as described previously in respect of the creation of dynamic pages.

As mentioned previously, at least some of the semi-static pages can be provided with action buttons or drop-down menus to allow the user to initiate an on 25 line transaction or process. By "transaction" it is meant any relevant process or transaction which the user can initiate, and which may be undertaken upon or using his data stored in the database. Thus, the types of transactions available to the user 16 may be simple transactions such as merely editing the user's address for storage in the database, or more complicated transactions such as initiating an insurance claim or making a money payment. The types of transactions available thus depend upon the application to which the present invention is put.

5 As an example, consider the case where an editing operation is to be performed. Here the relevant HTNIL form will have been generated in advance as a semi-static page and pre-populated with the user's present address information as presently held in the database. The form will contain one or more action buttons to allow the address to be updated OLTP, for example, buttons such as "UPDATE" or 10 "DELETE". The buttons allow the user to indicate that the particular selected transaction is to be performed.

When the user request an address change page, the pre-generated page Z_17 is sent to him out of the page-storage cache and the user uses his web browser to display the page. The user then reviews the present address information and makes 15 any necessary changes, and then selects the appropriate action button. The pressing of the action button causes the browser to send the page back to the system web server, where the new address infori-nation is read from the page, and the database updated. The semi-static address change page is then refreshed with the new address rz) information.

20 A discussion of how the present invention stores the process state will now be undertaken.

As discussed previously, the inability of traditional Web-based systems to store a process state has meant that it is difficult to perform complex processes, and hence the ma ority of usage of the Web is merely for displaying static units of 25 information in the form of Web pages. When dealing with communication processes ID tl on the Web, such as, for example, data entry, there has been a problem in the past that the end user may enter data which is incorrect, and then immediately log off from his 17 session with the back end database system before receiving confirmation that the data has been correctly entered on the database. In the past this has left conventional systems with the problem that they need somewhere to send the error messages from the back end system processing the data. However, because the user has terminated 5 his Web connection it is not possible to communicate the error to the user. As a result, the user will believe the data to have been successfully updated when this will not have been the case.

The present invention solves this problem through the provision of the private Web pages for each user, in that any error messages or other systems 10 communications indicative of the state of any particular process can be sent to the user's private Web pages for storage. This system effectively provides for storage of each user's process state by storing a message or other indicator or pointer to the state in the user's private Web pages. Hence, in the case where the user has logged off before receiving confirmation of an action then the next time the user logs into his 15 Web pages those pages will detail the errors or other extra infonnation thereon, and hence the user does not lose the "conversational" communication with the back end system, being communications where the process state is stored thus allowing references to earlier process actions in a user session. The storage of the process state for each user on their respective private Web pages allows for much more 20 complicated processes and database transactions to be performed than would otherwise be the case when a user process state is not stored.

With respect to the back end system 100 the state of the real processes being performed in the back end system are held within the parser means. The back end system effectively breaks down processes into small atomic steps or tasks and can 25 queue user processes at each and every stage. This allows for Web communications that may suddenly stop mid process at any stage (for instance because a user has logged off), and the parser means is also further arranged to effectively parallel 1- C 18 process many user sessions at any one time, hence it is possible to have many customer communications which have not been properly completed stored within the parser means at any one time.

As an example of a back end system 100 which can be used with the 5 present invention, the parser means 24 together with several other back end system elements can be implemented by means of the Amarta system, which is the trade name for a back end database management system which is designed and supplied by the applicants in respect of the present application, being Sherwood International Group Limited, 10 Various features of the application server 10 of the present invention will now be described.

The application server 10 preferably contains an element known as an Internet cartridae. The Internet cartridge can have access to the page just sent in by the user, and hence can use the data on this page to merge with the next page to be 15 sent out, as well as sending the data sent in by the user to the back end system for processing. Although the data on the page sent in by the user is kept only for a very short time (less than 0. 1 seconds) it can be considered to be indicative of the present process state of the user session, and can also be re-used since it means that there is no requirement for the application server to re-read the data sent in by the user from 20 the Website in order to send them back out.

Furthermore, the Internet cartridge provided within the application server may have the ability to pick a different page to progress to in a user session based upon a result communicated to the server from the back end system. Thus it is possible to define many paths from a single Web page using a simple status flag 25 returned from the back end system. For example, if the back end system returns a s t a t u s = 0 o ka Y I then the user can progress to the next screen, or if s t a t u s = - 1 t e r r or then the process progresses to the error screen. This approach of using the application server to specify in advance the next Web pages which the user might access in response to error or other information flags passed to the server from the back end system allows a Web desi ner to create multi-path screens from each 1 9 preceding screen. This allows powerful end user communication scripts to be written, Z7 5 including scripts which loop until the user gets it right. As a simple example. consider ID the case of a communication script to allow the user to enter information into the database via his Web page. Here, the ability of the application server to control the progress of the user through the Web pages allows the server to prevent the user from progressing until the data has been correctly entered and a successful data entry flag ID 10 has been received from the back end system. In practice, for example, the server may simply cause the data entry page to be re-shown with a request for data entry until it is communicated to the application server from the back end system that the data has been entered successfully on the database. Furthermore, the ability of the application ify which pages the user can progress to allows those pages to be server to speci 1-7 ID 15 generated in advance and cached in preparation for the actual user request therefor.

From the above description of a specific embodiment of the present invention, it will be apparent that the present invention solves the problem of concurrent multiple access to an online database by presenting the user specific information data in the database to the user via user specific Web pages, thus 20 separating the central database in the back end system from the data accessible by the user. Furthermore, the user specific Web pages are further divided into a number of different types, only one or some of which require access to the central database in the back end system in order to meet the user's request. By allowing user requests to be so separated, demand at any one time for access to the central database in the back 25 end system can be reduced, thus allowing the system to service many more site customers than would otherwise be the case.

Although in the above-described embodiments we have provided three C, different types of Web pages being static, semi-static, and dynamic, it will be understood that this need not be the case, and that a combination of two or more different types can be used as required. Where only two types of Web pages are used, these would be static pages and dynamic pages, static pacres and semi-static pages, or I t7l 5 semi-static pacres and dynamic pages as appropriate.

Claims

CLAIMS:

A method of providinc.; access to a database over a network, comprising the steps of.

5 pre-generating one or more user-specific data pages for a user, one or 1!P I'D more of said data pages being further arranged to allow the user to indicate that at least one transaction is to be performed; storincy each of said pre-generated user-specific data pages; receiving user requests for the user-specific data pages over the 10 network.- and transmitting the requested one or more of the user-specific data pages to the network for transport to the user in response to the received request; wherein said pre-generating and storing steps are performed in advance of the receipt of the user requests for the data pages.
2. A method according to claim 1, wherein one or more user-specific data pages are pre-created for a plurality of users, one or more of said data pages created for each user being further arranged to allow each respective user to indicate that at least one transaction is to be performed; and 20 wherein each respective user may request their own respective user- specific data pages over the network.
3. A method according to claims 1 or 2, wherein the indicated transaction is to be performed on or using user-specific variable data stored on the particular data 25 page.
4. A method according to claim 3, wherein the transaction an editi 7 1 ing process to be performed on the user-specific variable data stored on the user-specific data page.
5 5. A method according to claim 4, and further comprising the steps of receiving a previously transmitted user-specific data page having user speci ic variable data incorporated therein from a user over the network, said user having indicated that the user-specific variable data has been edited; and storing the user-specific variable data incorporated within the received 10 page in the database in place of or in addition to the user-specific variable data incorporated in the data page as previously transmitted.

1:1
6. A method according to claim 5, and further comprising the steps of re-generating the previously transmitted user-specific data page 15 incorporating the edited user-specific variable data therein in place of the previously transmitted user-specific variable data; and storing the re-generated data page in place of or in addition to the user specific data page as previously transmitted.

rn 20
7. A method according to any of the preceding claims, wherein the pre generating step is repeatedly performed periodically.
8. A method according to any of the preceding claims, wherein the pre generating step is repeatedly performed on command.
9. A method according to claims 7 or 8, wherein when the pre-crenerating step is repeated the previously stored data pages are replaced with the newly 2 generated data pages.
10. A method according to any of the preceding claims, wherein the pre generating step for each page comprises the steps of:

5 retrieving user-specific data from the database; and merging the retrieved data with a suitable generic data page template to give a user-specific data page.
11. A method according to any of the preceding claims, and further 10 comprising the steps of dynamically generating one or more further user-specific data pages after receipt of a user request in response to the received user request.

1
12. A method according to claim 11, wherein said further user-specific data pages are further arranged to allow the user to indicate that a process is to be 15 performed.
13. A method according to claim 11 or 12, wherein after said further user specific data pages have been dynamically generated in response to the user request, other user-specific data pages which are known in advance to follow the requested 20 page are pre-generated and stored in advance of the receipt of the respective requests therefor from the one or more users.
14. A method according to any of the preceding claims, wherein one or Z more of said user-specific data pages are further provided with one or more action 25 buttons each arranged to allow the user to respectively indicate that a particular process is to be performed.
15. A method according to any of the preceding claims, wherein said user specific data pages are further arranged to store an indicator to a process state.

C t__
16. A method accordinc, to any of the preceding claims, wherein said z:1 5 network is the Internet, and said user-specific data pages are mark-up language pages capable of being displayed by a browser.
17. A method of accessinc, a database over a net-work, access to which is provided by a database access provider in accordance with any of the preceding 10 claims, comprising the steps of:

transmitting a request for a user-specific data page to the database access provider over the network; and receiving the requested user-specific data page from the database access provider over the network.
18. A method according to claim 17, and further comprising the steps of.

rn indicating on the received data page that a transaction is to be perforrned; and transmitting the received data page incorporating the user indication to 20 the database access provider over the network.
19. A data page generation method for generating user-specific data pages C., incorporating user-specific data retrieved from a database, comprising, the steps of: retrieving user-specific data specific to a user from the database; generating a user-specific data page incorporating said user- specific 25 ZD data, said data page being further arranged to allow the user to indicate that a process is to be performed; and storing the generated user-specific data page; wherein the user-specific data page is generated and stored before it is requested by the user.

5
20. A data pacFe aerieration method according to claim 19, wherein said generating step includes the step of merging the retrieved data from the database with a suitable generic data page template to give the user-specific data page.

1.7 10
21 A data page generation method according to claim 19or 20, wherein one C) or more of said user-specific data pages are further provided with one or more action buttons each arranged to allow the user to respectively indicate that a particular process is to be performed.

15
22. A data page generation method according to claims 19, 20, or 21, M wherein said user-specific data pages are further arranged to store an indicator to a process state.
23. A data page generation method according to any of claims 19 to 22, 20 wherein said user-specific data page is in a mark-up language capable of being displayed by a browser.
24. A system for providing access to a database over a network, IM comprising-
25 page generation means for pre-generating one or more user-specific data I I pages for a user, one or more of said data pages being further arranged to allow the user to indicate that at least one transaction is to be performed; page storage means for storing each of said pre-generated user-specific data pages; page request reception means for receiving user requests for the user specific data pages over the network; and 5 page transmission means for transmitting the requested one or more of the user-specific data pages to the network for transport to the user in response to the received request; wherein said page creneration means and said pacre storage means respectively pre-generate and store the user-specific data pages in advance of the Z_ 10 receipt of the user requests for the data pages by the page request reception means.

C 25. A system according to claim 24, wherein said pacre generation means is further arranged to pre-crenerate one or more user-specific data pages for a plurality of users, one or more of the user-specific data pages created for each respective user 15 being further arranged to allow the user to indicate that at least one transaction is to be performed; and wherein each respective user may request their own respective user specific data pages over the network.

20
26 A system according to claim 24 or 25, wherein the indicated transaction is to be performed on or using user-specific variable data stored on the particular data page.
27. A system according to claim 26, wherein the transaction is an editing 25 process to be performed on the user-specific variable data stored on the user-specific data page.
28. A svstem accordina to claim 27, and further comprising:

page reception means for receiving a previously transmitted user specific data page having user-specific variable data incorporated therein from a user over the network, said user having indicated that the user-specific variable data has been edited, said page storage means being further arranged to store the user-specific variable data incorporated within the received page in the database in place of or in addition to the user-specific variable data incorporated in the data page as previously transmitted.
29. A system accordinCF to claim 28., wherein said page generation means is further arranged to re-generate the previously transmitted userspecific data page incorporating the received user-specific variable data therein in place of the previously transmitted user-specific variable data; and 15 said page storage means is further arranged to store the re-generated data page in place of or in addition to the user-specific data page as previously transmitted.
30. A system according to any of claims 24 to 29, wherein the page Z:' 20 Creneration means is further arranged to pre-generate the user- specific data pages Z C periodically.
A system according to any of claims 24 to 30, wherein the page generation means is further arranged to pre-generate the user-specific data pages 25 upon command.
32. A system according to claims 3) 0 or 3 1, wherein the page storage means I 28 replaces the previously stored data pages with the newly generated data pages.
33. A system according to any of claims 24 to 32, wherein the page generation means further comprise:

5 database access means for retrieving user-specific data from the database; and page merging means for merging the retrieved data with a suitable generic data page template to give a user-specific data page.

10
34. A system according to any of claims 24 to 33, wherein said page generation means is further arranged to dynamically generate one or more further C V user-specific data pages after receipt of a user request in response to the user request received by the page request reception means.

15
35. A system according to claim 34, wherein said further user-specific data pages are further arranged to allow the user to indicate that a process is to be performed.
36. A system according to claim 34 or 35, wherein after said further user 20 specific data pages have been dynamically generated in response to the user request, other user-specific data pages which are known in advance to follow the requested page are pre-generated by the page generation means and stored in the page storage means in advance of the receipt of the respective requests therefor from the one or more users.
37. A system according to any of claims 24 to 3) 6, wherein one or more of said user-specific data pages are further provided with one or more action buttons Cr each arranged to allow the user to respectively indicate that a particular process is to be performed.
38. A system according to any of claims 24 to 3 7, wherein said userspecific 5 data pages are further arranged to store an indicator to a process state.

0
39. A system according to any of claims 24 to 3 8, wherein said network is the Internet, and said user-specific data pages are mark-up language pages capable of being displayed by a browser.
40. A user system for accessing a database over a network, access to which is provided by a system in accordance with any of claims 24 to 39, said user system for accessing the database comprising:

page request transmission means for transmitting a request for a user 15 specific data page to the system for providing access to the database over the network; and page reception means for receiving the requested user-specific data page from the system for providing access to the database over the network.

20
41. A user system according to claim 40, and further comprising:

means for indicatino, on the received data page that a transaction is to be performed; and page transmission means for transmitting the received data page incorporating the user indication to the database access provider over the network.
42. A data page generation system for generating user-specific data pages incorporating user-specific data retrieved from a database, comprising the steps of Z database access means for retrieving user-specific data from the database; page generation means for generating a user-specific data page incorporating said user-specific data, said data page being further arranged to allow 5 the user to indicate that a transaction is to be performed; and page storage means for storing the generated user-specific data page; wherein said page generation means and said page storage means respectively pre-generate and store the user-specific data pages in advance of the receipt of user requests for the data page.

0
43. A data page generation system according to claim 42, wherein said page aerieration means further comprise:

page merging means for merging the retrieved data from the database L_ C 7 with a suitable generic data page template to give the user-specific data page.
44. A data page generation method according to claim 42 or 43, wherein one or more of said user-specific data pages are further provided with one or more action buttons each arranged to allow the user to respectively indicate that a particular process is to be perfori-ned.
45. A data page generation method according to claim 42, 43, or 44, wherein said user-specific data pages are further arranged to store an indicator to a process state.

25
46. A data page generation system according to any of claims 42 -to 45,

:M wherein said user-specific data page is in a mark-up language capable of being displayed by a browser.
47. A computer readable storage medium storing a computer program which when loaded into a computer is arranged to control the computer to perform the method steps of any of claims I to 16.

5
48. A computer readable storage medium storing a computer program which when loaded into a computer is arranged to control the computer to perform the method steps of claim 17 or 18.
49. A computer readable storage medium storing a computer program 10 which when loaded into a computer is arranged to control the computer to perform the method steps of any of claims 19 to 23.
50. A method of providing access to a database for a plurality of users, comprising the steps of:

15 storing user-specific data pages containing user-specific data, said data pages being of one or more different stored types; receiving user requests for data pages from a network; processing the user requests for data pages to determine the type of data page requested; generating a data page of another type to the stored types, if required; and transmitting the requested data page to the particular user who requested it across the network; wherein if the requested data page is of a type which has been stored 25 then the stored page is transmitted to the user, whereas if the requested data page is another type to the stored types then the requested page is dynamically generated before being transmitted to the user.

32
51. A method according to claim 50, wherein one of said stored types of pages are static pages.
52. A method according to claim 50 or 5 1, wherein one of said stored types 5 of pages are semi-static pages, wherein the user-specific data contained therein may be updated.
53. A method accordina to claim 52 wherein the user-specific data is updated repeatedly periodically.
A method according to claim 52 or 53, wherein the user-specific data is updated on command.
55. A method according to any of claims 50 to 54, wherein said stored user 15 specific data pages are generated in advance of the user requests therefor, and are C further generated in the same manner as said data pages of another type which are dynamically generated.
56. A method according to claim 5 5, wherein the generation of pages of any 20 type comprises:

retrieving the relevant user-specific data from the database; mergino, the retrieved data from the database with a suitable Generic data CI page template to give each user-specific data page.

I- Z 25
57. A method according to any of claims 50 to 56, wherein said user- specific data pages are further arranged to store an indicator to a process state.

I I
58. A method according to any of claims 50 to 57, wherein one or more of said user-specific data pages are further provided with one or more action buttons each arranged to allow the user to respectively indicate that a particular process is to be performed.
59. A method according to any of claims 50 to 58, wherein the userspecific data pages are each in a mark-up language capable of being displayed by a browser.
60. A system for providing access to a database for a plurality of users, 10 comprising:

page storage means for storing user-specific data pages containing user specific data, said data pages being of one or more different stored types; means for receiving users requests for data pages from a network; request processing means for processing the user requests for data pages 15 to determine the type of data page requested; page generation means for generating a data page of another type to the stored types, if required; and page transmission means for transmittin the requested data page to the 1.7 9 1:7 particular user who requested it across the network; 20 wherein if the requested data page is of a type which has been stored C then the stored page is transmitted to the user, whereas if the requested data page is of another type to the stored types then the requested page is dynamically generated by the page generation means, before being transmitted to the user.

V 25
61. A system according to claim 60 wherein one of said stored type of pages are static pages.
62, A system according to claims 60 or 61, wherein one of said stored type of pages are semi-static pages, wherein the user-specific data contained therein may be updated.
5 631 A system according to claim 62, wherein the user-specific data is updated repeatedly periodically.
64. A system accordincy to claims 62 or 63, wherein the user-specific data is updated on command.
65. A system according to any of claims 60 to 64, wherein said stored user specific data pages are generated by the page generation means in advance of the user requests therefor, and are further generated in the same manner as said data pages of another type which are dynamically generated.
66. A system according to claim 65 wherein the page generation means further comprise:

database access means for retrieving the reelvant user-specific data from C5 the database; and 20 page merging means for merging the retrieved data from the database C, with a suitable generic data page template to give each user-specifid data page.
67 A system according to any of claims 60 to 66, wherein said userspecific data pages are further arranged to store an indicator to a process state.
68. A system according to any of claims 60 to 67, wherein one or more of said user-specific data pages are further provided with one or more action buttons each arranged to allow the user to respectively indicate that a particular process is to be performed.
69. A system according to any of claims 60 to 68, wherein the userspecific data pages are each in a mark-up language capable of being displayed by a browser.