AU722589B3 - Method of local field verification - Google Patents

Description

METHOD OF LOCAL FIELD VERIFICATION This invention relates to an improved method of verifying the correctness of data entered in a field of a form and verifying the identity of a user and storing forms within a client library. In particular, the method is useful for forms submitted to an application running via the World Wide Web in a standard browser.

BACKGROUND TO THE INVENTION The World Wide Web has created a revolution in information transfer and dispersed processing. An application running on a server will collect information from a client and process the information at the server rather than at the client. This is a significant development compared to traditional application processing that occurs on the local machine (client).

An essential aspect of server-side information processing is the collection of the data. The most common method for information collection is with the use of forms. The primary browsers (Netscape Navigator® and Microsoft Internet Explorer®) support the use of forms for information collection. Applications requiring server-side processing include payment processing for on-line purchasing, user data collection, registrations, sales orders, purchasing, change of password, etc.

An example of server-side processing may be found in United States patent number 5737592, assigned to International Business Machines Corporation. This patent describes a method of accessing a relational database over the Internet. A user requests information from the database via HTML input forms. The forms are converted to SQL statements for execution by the relational database management system.

These statements are returned to the server, processed (server-side) and then the results of the query are converted back to HTML for presentation to the client.

A typical form for information submission requires-multiple fields to be completed. The majority of the fields require information to be presented in a defined format, for example an eight-figure date dd/mm/yyyy). Also, some fields are designated as essential while others are optional. Before registration of the information by the application it is necessary for many of the fields to be checked (or verified) for correct format and/or correctness of data. A product sales form or Invoice Form).

Field verification occurs at the server. This requires the user to fill out the fields at the client machine and to submit the form to the server for verification. If information in a single field is in the incorrect format, the form is rejected. It will be appreciated that in the example described in US5737592, the fields must be correct if an accurate query statement is to be constructed. If an incorrect field is identified, a suitable notice is returned to the client and the form is redisplayed for correction, after an appropriate error message is displayed. Due to the time required for data transfer and processing, a considerable delay can be caused by this process. An improved method of field verification is required.

Similar problems occur with user identification (sometimes referred to as authentication, verification or validation). Existing methods store identification strings (cookies) on a user's computer to identify a user the next time they access a site. The verification occurs at the server so the process can be slow for the reasons discussed above. This method is usually quite limited in detail and lacks correctness of identification and security.

One known approach to solving the above, is to provide a dedicated application running on the client machine that provides user identification and some local field verification. One such product is NetBank operated by the Commonwealth Bank of Australia. When the NetBank web page is accessed a client can register to download the software. Once downloaded the software is run to access data maintained on a server at the bank.

The first time the software is run a verification string is stored on the client machine and the server. When the software is run after the first operation, the verification string is checked to identify that the software is a legitimate version registered with the bank. The software provides a menu of operations that ensures strict accuracy of the syntax of requests sent to the server.

Although the NetBank software goes some way to solving the problem of field verification, it does so in a very limited way that cannot be generally applied to web based applications.

This technique is commonly known as dedicated client/server software where the client portion can only be used for access with the specified server portion of the software and serves no other purpose.

One of the major downfalls with this type of operation is what happens when a corruption occurs on the client system and damages the client-side software, or the client wishes to use a computer system in another location? The usual result is a complete download and reinstallation of the software, along with a full re-registration with the server. Typically all settings and identification are lost and need to be reestablished.

OBJECT OF THE INVENTION It is an object of the invention to provide an improved client-side method of local verification for Web based Forms, whilst using a standard Web Browser.

Further objects will be evident from the following discussion.

SUMMARY OF THE INVENTION In one aspect, although it need not be the only outline or indeed the broadest aspect, the invention resides in an improved method of local verification in a computer network environment including the steps of: downloading a library of verification tools; storing the tools in a local repository; accessing an information sensitive application on an application server; invoking a form containing one or more fields; performing local field verification by invoking one or more of said verification tools from said library of verification tools; adjusting field content as required until all fields are verified; and submitting said form to said application server.

In preference, the step of downloading a library of verification tools can be downloading from a web site, a compact disc, a floppy disk or other medium. Downloading preferably occurs once but may be updated.

The local repository is suitably a hard disk on a local computer.

The step of accessing an application server may be via an intranet, an extranet, or the internet.

The step of performing local field verification is preferably activated by recognising a URL of a web site that is enabled for local field verification.

In one aspect of the invention, the form is invoked from the library of verification tools.

Preferably, field verification involves local checking of field format.

Alternatively, field verification may involve local checking followed by retrieval of information from the application server.

In another aspect, the method further includes the preliminary step of user verification and/or identification.

The library of verification tools preferably includes standard tools, standard forms, autofill fields and other tools.

BRIEF DESCRIPTION OF THE DRAWINGS Preferred embodiments of the invention are described with reference to the following figures in which: FIG 1 is a block diagram of the invention; FIG 2 is a flow chart of a prior art field verification method; FIG 3 is a flow chart of field verification according to this invention; FIG 4 is a block dataflow of the invention; FIG 5 is a sample application overview for the invention and; FIG 6 is an overview of the global structure and central repository.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Referring to FIG 1, this shows a block diagram of the invention. A user operates standard Web Browser Software 1 on a computer system 2.

The user accesses a specific AWWVW site across an intranet or internet 8 that may activate the invention's optional user identification library 13.

Additionally, an optional authority token 3 can be passed to the site, as a background task. The WWW site presents a Web Page 10 that invokes a Web-based input form This form can be delivered either from the Web Page 10 or from the client-side verification library 6, the later is preferred.

The user inputs information into the fields 5 on the form 4. The fields 5 are formatted by accessing a verification library 6 stored on the computer system 2. One or more field verification tools stored in the verification library 6 may be applied to verify and/or update the content of a field Should the content of a field 5 be incorrect, a suitable message is immediately displayed to the user from the verification library 6 so that corrective action can be immediately taken. When all fields 5 are verified as correct, the form's data is submitted in HTML format 7 or suitable webbased format to the Internet or Intranet 8.

The prior art method of field verification is shown in the flow chart of FIG 2. A user locates a WWW site and accesses a Web Page 10 using a computer system 2 and a standard browser-i, as described above. The server may search for and update a cookie 9 on the computer system 2; this is a background task that the user usually does not see. The user invokes a form 4 that has a number of fields 5. The user fills out the form as before 11, but in the prior art method the completed form is submitted 12 to an application server 18 for checking. If the form is correct 14 the data is processed 15 at the application server 18 and the results are presented to the user. If the form data is incorrect 14, the form is returned 16 to the user for correction and resubmission. In many prior art methods, the form is cleared in this process so the user must re-key all the information previously submitted.

A flow chart showing an improved method of field verification is depicted in FIG 3. As before, a user connects to the World Wide Web Site using a computer system 2 and a standard web browser 1. The user accesses a specific WWW site and this URL Address may activate the optional user identification library 13. Depending upon configuration, one or more of the ID options from the user identification library 13 may be utilised for verification or not. Additionally, an optional authority token 3 can be passed to the site, each as a background task, from the client library. The WWW site presents a Web Page 10 to the standard browser 1. The user invokes a Web-based form 4, which has a number of fields This form is obtained either from the invention's libraries 6 or from the application server 18, the prior is preferred. The user enters 11 the required information in the fields 5 of the form 4. The content of each field is verified dynamically 19 using the field verification tools stored in a field verification library, which is stored on the user's computer system 2. If the content or format of a field is incorrect the user is immediately notified and can correct the substance of the field dynamically and without delay.

Optionally, some fields may require on-line verification 20 to, and/or supplementary data from, the application server 42. Using the field verification tools, a request statement is generated 22 and parsed back 23 to the application database. The server 18 processes the request and returns 24 the data to the relevant field or fields 5 on the form 4. When all fields are correct the form is submitted 21 (either automatically or manually) and the result(s) presented to the user, as required. Because the fields are already verified there is no delay in submitting (or obtaining) the information.

One example of a field verification tool is to check that the content of a date field is in the required eight-digit format 01/01/2000) and that a legitimate date is entered. One example of an on-line verification tool is the testing of stock availability for a product code entered onto a Sales Invoice form.

The inventor's verification and identification tools (Library) may be written in any language(s) useable by the browsers. These may include JAVA, Visual Basic, Applets, C programs, dynamic link libraries, APIs, etc.

The Library would be stored in a local repository on the user's computer system by downloading it from a web site or by uploading from a floppy disk or compact disk. An appropriate version of the library to suit the browser being used may be required. The library may interact with the browser in a similar manner to a "Web Browser plug-in".

The inventor envisages that the Library will be in several sections, but not limited to these, as diagramed in Fig 4. The primary section consists of a master or core library of common tools, which will be generally available. The Common tools will consist of, but not be limited to: 1. Standard Field Verification Tools 31 o Dates Several Formats u Alpha Only, Numeric Only, Pattern Matching Formats o Capitalisation, Lower Case, Upper Case Formats o Time Several Formats o Alignment Left, Centre, Right o Currency Several Formats o On-Line Field to Application Database Verification Update o Read Only Field or Display Field 2. Standard Forms 32 o Password Verification Only o User Name and Password Verification o ID Code, User Name and Password Verification o Logon Screen o Change of Password(s) Form o Registration Form o Remove a User Form o Add a User Form New User or Existing User o Backup of Data Form o Feed Back Forms Several Formats 3. Standard AutoFill Fields 33 o User- Name, Address, E-mail, Phone, etc.

o Date Several Formats o Company Address, E-mail, Phone, etc.

o Time Several Formats 4. Standard Other Tools 34.

The core library will also contain several database structures of which a Registration Database, a Corporation Database and a User Database will be desirable. These databases may contain, but not be limed to, such information as User Details, Company Details, Address locations, Associated URL Addresses, Registration Codes, Security Codes, Passwords, Cryptology Codes, Expiry Dates, Access Levels, etc.

User add-on or custom libraries 41 can be created for individual or corporate web sites using a provided Developers Toolkit 40, or suitable development tools that may be available. An HTML programmer or Web Developer would utilise the Library Developers Tool-Kit 40 to create a custom library 41. Once created and compiled, the custom library is then distributed to users of the Web Site. The invention's toolkit 40 and/or the Master Library 30 would maintain version control. Web Developers design forms that specify the routines within the libraries that are used as verification for each field. All programmers will be able to access the master library 30 of standard verification tools as well as the tools developed for their own custom library 41. The simplicity of this means that a single line of Web-based code may be used to invoke a complex form with many field verification techniques and on-line checking, etc. directly from the invention's libraries.

The Library will reside on a client's computer system 2 and remain independent of any server 17 and/or Web browser 1.

Custom Libraries, for example, might provide functionality for encryption, transaction clearing, specific on-line request statements, custom field verification, custom forms, etc. The custom library is merely an extension of the core library and is therefore reliant on the core library to function as a whole. Users whom already have the core library need only install the new custom library, else the user will need to install and register the core library first.

The master library is maintained on the inventor's Web Server, along with any number of mirrored sites. The custom libraries would be located on the server for the web site to which they relate and may, optionally, reside on the inventor's Web Server(s). This invention provides continuity of programs and user data, along with a distribution model that provides surety and security for the users libraries and databases. This method can provide a means to replicate personal data across several computer systems, ensuring continuity and reliability of databases and libraries.

In one embodiment, the library 30 provides active user authentication 13 and token authentication 3. A catalogue of URLs that the user accesses, that utilise the invention, is stored with the user's master library database 39. When a user accesses a site, the URL of the accessed site 36 is compared to the catalogue of URLs held in the user's database 39. When the URL is recognised, an identification token 3 is sent with the URL to notify the server that the user has authority to access the site. This token provides details of security level, access levels and the correctness of the user, etc. Depending upon the actual security access requirements for the URL, the level of security activated from the registration database 37 can be enhanced by means of a password and/or user-name form. The fields on this form may be text based or encrypted, additionally any of the available authentication techniques 35 (such as voice, iris pattern, etc.) may be employed.

In some cases, a user may wish to access web sites from more than one computer Work, Home, Laptop, etc.), as per Fig 6. Once a user has registered a license of the master library, they can download it onto several PC systems for their individual use 2a, 2b, 2c. Should a 'remote or foreign PC' already have the core library installed, a user can add themselves to this library and update their data onto that PC. Users can securely remove themselves from a core library on a PC at any time.

All registered user's details and information will be stored at a central secure repository 17a on the inventor's Web Site (and mirrors 17b, 17c, 17d, 17e) to allow for this type of global roaming. Access to the user's data enables instant updating of information held on roaming PCs from the accessible Web Site(s) 17a, 17b, 17c, 17d, 17e. Each user will be required to authenticate themselves prior to downloading their data. Where a PC has several users within the core library, one user cannot obtain access to another user's details or information without the appropriate security access codes. These codes (similar to pin numbers) are set within the core library and are established by each user upon registration of the core library. The users data, held on the central and mirrored repositories, may be encrypted (for security, privacy and safety reasons) and the decryption key could be the users security access codes.

Personal modifications or tailoring of the core library will be replicated onto the central 17a and mirrored Web Sites, 17b, 17c, 17d, 17e along with changes or updates that a user implements from time to time. The core library will check against the replicated database, as a background task, to maintain continuity and security of each user's details and information, etc.

It will be appreciated that the method of local field verification described herein provides a significant reduction in the time required in obtaining and submitting a Web-based Form. Furthermore, the field verification is dynamic in two senses: 1) All fields are checked before the form is submitted to the server providing fast and reliable data to the server.

2) Each field can be on-line submitted, as it is completed, rather than waiting for the entire form to be completed before submission. This allows information to be downloaded to the user while the remaining fields are completed. This feature is described below with reference to the sales form example.

The core library may contain standard forms, which would further reduce the time necessary to transmit information. For example, an HTML programmer wishing to provide a feedback form could utilise a standard feedback form supplied with the master library. The form would then be displayed directly from the library rather than downloaded from the web.

This provides additional time saving techniques and improves resource efficiency.

It is anticipated that the master library will require occasional updates. The library contains a tool to update itself in the background when a web site is accessed that is aware of the invention or the user accesses the inventors' Web Site or requests the core library to investigate for updates.

FIG 5 describes a specific implementation of the invention with reference to an on-line sales order transaction from withina Web-Based Accounting System on an application server 18. As before, a user accesses a web site that implements the invention. The URL catalogue database in the master library recognises the site as implementing the invention and accesses the User's ID configuration for this URL. The option has been set to request the user's password. The user enters the password and presses the "OK" button. The Invention then sends an appropriate identification code to the server. The server checks this code and supplies an acknowledgement; the libraries also check whether an upgrade may be required. The user is then provided suitable access to the web site.

The user selects a sales option from the Web Page (as presented) which results in the web page making a call to the master or custom library to display a standard or custom form 4 in the users browser. The user commences entering 11 information in the form. Each field 5 is verified as it is completed. Some fields may be transmitted 20 to the web server for immediate retrieval of information. For example, entering the Customer Number may retrieve the customer's name and billing address; whereas entering a Stock Code may retrieve a full description, price, the stock holding and stock availability for that product.

When all fields have been completed, the user submits 21 the form, which transmits to the web server 17 and receives rapid confirmation from the application server 18, since no server-side checking is required.

Optionally, the server 18 may preserve the on-line data and wait for the "Acceptance" from the form 4 to finalise the transaction(s), along with any extra information that the form may contain.

The invention described herein offers a number of advantages compared to existing field verification techniques: 0 Increased Performance and reduced Network Traffic; SImproved functionality of Internet and Intranet based applications; The size of Web-based forms is reduced by removing field verification from the downloaded web pages and from the application server or even the form itself from the application server; The field verification core library remains resident and can be reused and updated, along with supporting any number of Custom Libraries; The library checks itself for authenticity through the user authentication process.

Throughout the specification the aim has been to describe the invention without limiting the invention to any specific combination of features.

Claims (3)

1. A method of local verification in a computer network environment including the steps of: downloading a library of verification tools; storing the tools in a local repository; accessing an information sensitive application on an application server; invoking a form containing one or more fields; performing local field verification by invoking one or more of said verification tools from said library of verification tools; adjusting field content as required until all fields are verified; and submitting said form to said application server.

2. The method of claim 1 wherein the step of performing local field verification is activated by recognising a URL of a web site that is enabled for local field verification.

3. The method of claim 1 further including the preliminary step of user verification and/or identification.