GB2372338A

GB2372338A - Electronic product trading

Info

Publication number: GB2372338A
Application number: GB0023711A
Authority: GB
Inventors: Majid Jahanshahi
Original assignee: EASYMATERIAL COM Ltd
Current assignee: EASYMATERIAL COM Ltd
Priority date: 2000-09-27
Filing date: 2000-09-27
Publication date: 2002-08-21
Also published as: GB0023711D0

Abstract

A central server (10) facilitates trading in building/construction materials, is accessible by a plurality of clients (40-48) via the Internet, and is connected with a plurality of transaction servers (50-58). Each transaction server connects via a corresponding one or more intermediary servers (70-80), using a private line connection (130-136), to a database (110-120) which is maintained with a stock list of building and/or construction materials for a particular supplier. Each supplier database (110-120) updates a central database (20) local to the central server (10) via the private line connection (130-136) with that supplier's current stock. The central database (20) employs a 'pocketed' structure which increases data access speed. Each client (40-48) accessing the central server (10) is provided with a menu arranged in a specific manner for ease of product searching. Results of the search are displayed according to user defined criteria such as proximity of supplier, ability to deliver and so forth.

Description

SYSTEM AND METHOD FOR ELECTRONIC PRODUCT TRADING

Field of the Invention This invention relates to a system and a method for the electronic trading of products, in particular construction and building materials.

Background of the Invention Large quantities of building and construction materials are purchased annually by the construction industry. At each stage in the construction of property, a range of different products must be obtained, often from a variety of different suppliers.

It is also necessary that any supplier which is approached for a given product is capable of meeting maximum delivery times and can offer the product at a competitive price.

Traditionally, goods have been purchased by issuing a tender to various suppliers, and waiting for each supplier to reply to the tender before choosing the appropriate supplier on the basis of product availability or cost. There are several drawbacks with this. The purchaser needs to have a detailed market knowledge if he or she is to ensure that a tender is offered to all potentially suitable suppliers. Often this requires that the services of a site manager or architect are retained. Moreover, the time taken to respond to written tenders means that, at each stage of the building process, forward planning is essential if delays in construction are to be avoided.

With the advent of electronic mail, the time taken to complete the tender process has been reduced.

Some builders merchants also offer a web site advertising their products. Nevertheless, the location and purchasing of building and construction materials at an optimum price is still a time-consuming and expensive exercise.

It is an object of the present invention to provide both a system and a method allowing building and construction materials to be sourced and purchased more rapidly than has to date been possible.

Summary of Invention According to a first aspect of the present invention, there is provided a method of facilitating the purchase of building/construction materials, comprising the steps of: storing on data storage means, for each of a plurality of suppliers of building/construction materials, at least one purchasing parameter set including at least one purchasing parameter selected from the list comprising availability, physical proximity, delivery time, and price, and relating to one or more specific building/construction materials; accessing, from a remote location, the said data storage means, via a central server in communication with the said data storage means; obtaining, at the remote location, an array of information including the or each purchasing parameter set supplied by the plurality of suppliers and relating to at least one of the specific materials; and comparing, at the remote location, equivalent purchasing parameters, provided by different suppliers for a given specific material, and obtained from the data storage means via the central server, so as to allow purchase of that given specific material from the supplier or those suppliers for which one or more purchasing parameters in a purchasing parameter set are considered most favourable.

The method of the present invention allows customers, both private and trade, simultaneously to compare prices, delivery times, availability and so forth of different suppliers and execute transactions with them, thus allowing the terms of purchase to be

optimised without the need for the lengthy tendering process. Moreover, the central server facilitates the transfer of information between a potential customer and a limitless number of suppliers. Particularly for private purchasers, the server and database structure allows them to identify building/construction materials to be purchased and they will then receive information from local suppliers which they may not even have been aware of.

In one preferred embodiment, the data storage means is a database, such as a relational database, which is local to the central server. This arrangement provides for rapid provision of desired information to customers at remote locations. The drawback, however, is that the local database needs to be updated by suppliers on a regular basis.

Particularly for trade customers, where suppliers may provide bulk discounts, it may become impractical to maintain all of the information on a central database local to the server. In that case, preferably, the data storage means may additionally or alternatively comprise a plurality of databases each local to a respective supplier. Nowadays, almost every supplier maintains their own database of available stock, prices, and so forth to allow rapid dealing with personal callers or telephone enquiries. The arrangement of the preferred embodiment routes enquiries from a customer, via the central server, to the various suppliers'databases. The particular manner in which the central server routes enquiries to the various suppliers'databases forms an important preferred feature of the present invention. The method, in particular, may further comprise providing a library of software applications, each application, when executed, permitting the routing of a request from the remote user to at least one of the plurality of suppliers. Employing a library of software

applications is advantageous because it optimises the speed of connection between the remote user and the suppliers'database. Potentially, thousands of suppliers'servers may be accessed, and each server may have physically different hardware and run different operating systems. If every supplier server were different, then the central server would otherwise require a program including code to connect to each and every single server. Such a program would be enormous and would take a very long time to execute.

Realistically, a single remote user would only require to connect to perhaps five supplier servers, assuming they wish to restrict their search to suppliers in the geographically local area. Using libraries allows each individual copy of the program which manages the connection between the central server and the suppliers'server to streamline itself for the user's requirements. In particular, the preferred step of accessing the data storage means from the remote location may include the steps of: accessing the central server from the remote location; identifying the specific material for which the said purchasing parameter set is to be obtained; selecting from the library of software applications, those applications which when executed will permit routing of a request from the remote user only to a selected subset of the totality of available suppliers; executing those selected software applications in response to a request, from the remote location, for information from one or more of the chosen subset of suppliers; and connecting the central server to the database that is local to the or each supplier in the chosen subset, so as to permit the said array of information to be obtained.

Most preferably, the or each of the chosen subset of suppliers may have a supplier server remote from

the central server, and the central server may be in communication with a plurality of transaction servers local thereto. In that case, the step of accessing the said storage means may further comprise: routing a request for information regarding a specific building/construction material from a remote location, via the central server, to one of the transaction servers; validating the said request at that transaction server; securely connecting between the said transaction server and the remote supplier server; and routing the request to the said remote supplier server.

In accordance with another preferred aspect of the present invention, the method may further comprise: displaying, at the remote location, a menu of a plurality of different building/construction materials; selecting from that menu, at the remote location, a specific one of the different building/construction materials ; and displaying at the remote location the purchasing parameter set supplied by the plurality of suppliers and relating to the specific material selected from the menu.

Providing the information in the form of a menu, and, most preferably, a tree structure, allows customers, and especially D-I-Y customers, to locate the building/construction material of interest rapidly and intuitively. In one embodiment, the method may further comprise: selecting at the remote location and from a top level menu, a general category of building/construction materials of interest from a range of available categories; displaying a range of specific materials each belonging to the selected general category; and selecting the given specific material from the range of specific materials so as to permit the said step of comparing the equivalent purchasing parameters for that given specific material.

It may be desirable to employ a cascading tree structure to search for building/construction materials when a large number of materials are offered. Preferably, therefore, the method further comprises: selecting, at the remote location and from a top level menu, a general category of building/construction materials of general interest from a range of categories ; displaying a lower level menu of sub-categories of building/construction materials relating to the selected general category in the top level menu ; selecting, from the lower level menu, a sub-category of building/construction materials of interest; displaying a range of specific materials each belonging to the selected sub-category previously displayed as part of the lower level menu; and selecting the given specific material of interest from the range of specific materials so as to permit the said step of comparing the equivalent purchasing parameters for that given specific material.

Alternatively, the method may further comprise: selecting, at the remote location and from a top level menu, a general category of building/construction materials of interest from a range of available categories; displaying, consecutively and in accordance with user selection, a plurality of lower level menus of increasingly specific sub-categories of building/construction materials relating to the selected category in the top-level menu; displaying a range of specific materials each belonging to the most specific of the user selected sub-categories previously displayed in the lowest of the plurality of lower level menus ; and selecting the given specific material of interest from the range of specific materials so as to permit the said step of comparing the equivalent purchasing parameters for that given specific material.

In the presently preferred embodiment, up to

seven levels of categorisation of materials are envisaged. An important (though preferred) feature of the menu structure is that it is designed in accordance with architectural procedures for the building of, for example, property. In other words, the top level groupings of different building/construction materials follow the temporal progress of the construction of such a property.

Preferably, the or each menu is stored at the central server as a menu data file. In that case, the method may further comprise compressing the or each menu data file at the central server before forwarding it or them from the central server to the remote location. The contents of the database local to the central server may also be compressed and forwarded from the central server to the remote location. In a particularly preferred embodiment, both the file or files making up the corresponding menu or menus are compressed along with the contents of the database local to the central server, and both or all are then "zipped" together to form a composite, compressed file. This may then be forwarded to the remote user so that all searching may be done locally to the remote user rather than across, for example, the Internet which would slow processing down considerably.

Preferably, the or each such file may be encrypted before forwarding, to improve security.

According to yet another important, preferred aspect of the present invention, the array of information to be forwarded to the remote user may be stored in a multi-dimensional, relational database.

The method may then further comprise: dividing the database into a plurality of pockets, each pocket being chosen in accordance with an appropriate corresponding general category of building/construction materials ; allocating each specific building/construction material to one of the

plurality of pockets within the said multidimensional database in accordance with the chosen appropriate general category; and storing an identifier for each specific building/construction material so allocated in the database, along with the or each purchasing parameter associated with that specific building/construction material.

In that case, in a particular database pocket, each specific building/construction material may be allocated in the database to a chosen one of a further plurality of sub-pockets containing data on subcategories of building/construction materials, each sub-category being more specific than the general category to which it belongs.

The advantage of using a"pocketed"relational database is that it may be searched significantly more rapidly than a standard multi-dimensional relational database. This is because the time taken to search a database increases as the exponent of its size, and by creating a database with pockets, a plurality of separate databases are, in effect, generated. Thus, the pocketed database structure is significantly quicker to search.

In accordance with a second aspect of the present invention, there is provided a computer system for facilitating the purchase of building/construction materials, comprising: a data storage means, upon which is stored at lest one purchasing parameter set including at least one purchasing parameter selected from the list comprising availability, physical proximity, delivery time, and price, for each of a plurality of suppliers of building/construction materials, and relating to one or more specific building/construction materials; and a central server in communication with the data storage means, the central server being configured to receive a request from a remote user for information from a purchasing

parameter set and relating to building/construction materials ; to access the data storage means, and to forward to the remote user an array of information including the or each purchasing parameter set supplied by the plurality of suppliers and relating to at least one of the specific materials; whereby the equivalent purchasing parameters provided by different suppliers for a given specific material may be compared at the remote location so as to permit purchase of that given specific material from the supplier for which one or more purchasing parameters in a purchasing parameter set are considered most favourable.

The invention also extends to a computer program product comprising program elements which, when executed upon the central server, cause the method of the invention to be carried out. In yet a further aspect, the invention provides a server loaded with such a computer program product.

Further preferred features of the present invention are set out in the dependent claims attached hereto.

Brief Description of the Drawings The invention may be put into practice in a number of ways, and one embodiment will now be described by way of example only and with reference to the accompanying drawings, in which: Figure 1 shows a computer system embodying an aspect of the present invention, including a central server and a plurality of clients connectable thereto; Figure 2 shows a screen shot of a menu of building/construction materials presented to a user at a client, following connection to the server of Figure 1; Figure 3 shows a screen shot of the results of a search, as displayed to the user, for a particular

building/construction material selected from the menu of Figure 2 ; Figure 4 shows a screen shot of the materials selected from a purchase by the user having reviewed the search results as shown in Figure 3; Figures Sa and 5b show screen shots of a payment/delivery screen and an order confirmation screen respectively, for the purchasing of the material selected and as shown in Figure 4; and Figure 6 shows a database structure for storing information on building/construction material.

Detailed Description of a Preferred Embodiment Referring first to Figure 1, a computer system embodying an aspect of the present invention is shown.

The computer system comprises a central server 10 which, in the currently preferred embodiment is a Dual Zion processor system running Red Hat Linux, Qmail, apache and Modssi with 1Gb Ram. Apache has been configured to use PHP4 which is optimised using a Zend Engine. The central server 10 is linked to a central database structure 20 which, in the preferred embodiment, includes a plurality of MYSQL databases. A plurality of files,"cookies"and other programs, as set out below, are loaded onto the central server 10.

Remote access to the central server 10 is secured with a first fire wall 30.

In use, and as will be understood by those skilled in the art, one or more of a plurality of clients 40,42, 44,46, 48 is able to access the central server 10 via the Internet. Each of the clients 40-48 is typically a personal computer with web browsing software (such as Microsoft (R) Internet Explorer ("'or Netscape Navigator (').

The central server 10 is also connected to a plurality of transaction servers 50,52, 54,56, 58 through a second firewall 60. Each of the transaction

servers 50-58 in the preferred embodiment employs a Cobalt Raq system running PHP and apache, and permits communication between the central server 10 and one or more of a plurality of intermediary servers 70,72, 74,76, 78,80 which are typically physically located at the premises of a supplier of building/construction material behind a third firewall 81. The intermediary servers are preferably a Windows ('-NT workstation operating using a mixture of software applications.

Each intermediary server is in turn connected to the LAN server or other database management computer for that particular supplier. Thus, as may be seen in Figure 1, a first intermediary server 70 for"supplier 1"is in communication with a first supplier server 90 which controls access to a first supplier's database 110. As will be appreciated, both the first supplier server 90 and the first supplier database 110 are typically already present at the supplier's premises, prior to the setting-up of the system of Figure 1 to manage and advise locally on stock, prices and so forth. Separate supplier servers 92,94, 96,98 and 100 are connected to respective intermediary servers 72,74, 76,78 and 80 for suppliers 2,3, 4,5 and 6 respectively. Each of the supplier servers 92-100 are in turn connected to supplier databases 112,114, 116, 118, and 120.

It is typically envisaged that connection between one of the transaction servers 50-58 and one of the intermediary servers 70-80 will be by means of private line connections. These are illustrated in Figure 1 at reference numerals 130,132 and 134 respectively. The use of these private line connections entirely removes the possibility of"hacking". Nevertheless, in certain circumstances, it may be desirable to use a secure socket layer (SSL) via the Internet, and such a connection is shown between the fourth transaction server 56 and the intermediary server 76 of the fourth

supplier.

As will be explained in further detail below, a plurality of transaction servers 50-58 is necessary because of the virtually limitless number of permutations of server and database which different suppliers may use. Computer-based inventory databases have been available for many years, and both the hardware and software necessary to allow connection to, say, a simple system using a flat database structure will be dramatically different to the software and hardware necessary to allow connection with interrogation of a modern LAN with information stored on a Oracle ITMI database. The algorithms and techniques employed by the system of Figure 1 to optimise access to all of the various supplier databases 110-120 from the single, central server 10 will be described below.

Having described the presently preferred hardware in the system of Figure 1, the method of obtaining building/construction material information at the remote clients 40-48, from either the central database structure 20 or one of the plurality of supplier databases 110-120 will now be described.

Suppliers of building/construction materials access the central server 10, typically via a private line connection 130-136. For example, supplier 1 may connect to the central server 10 via private line connection 130, to access his own, dedicated, central database within the central database structure 20.

Supplier 1 has full control over his own dedicated central database at the central database structure 20 with password protection. Each of the different suppliers'central databases, resident in the central database structure 20, is completely separate from each other supplier's dedicated central database therein, for security purposes. Supplier 1, for example, might access his own central database in the

central database structure 20 on a daily or weekly basis (depending upon volume and movement of stock, typically) and will provide information, for each of the building/construction materials which he offers for sale. For example, the price (which may be divided into bands depending upon volume purchased), current availability, delivery time, delivery price, and so forth may be stored within the central database.

In addition to the table of products offered by a particular supplier and stored along with retail price etc. in the central database, a second table is also provided within the central database structure and dedicated to a particular supplier. This table is updated by the server as it is accessed by remote clients 40-48 to provide a database of statistics accessible by the supplier to whom that second table belongs and to indicate to that supplier which customers have bought which products.

To initiate an enquiry to the central database structure 20, a client, such as the first client 40, connects to the central server 10 via the Internet.

Once initial connection is complete, which procedure will be familiar to those skilled in the art, a first customer at the first client 40 is invited to identify himself to the central server 10. Such information as name, address, telephone number etc. is requested.

Such information is, in the preferred embodiment, stored on the central database structure 20. A 'cookie'is then generated and sent back to the client 40 for storage in a web browser operating thereon. The cookie contains only two pieces of information.

Firstly, the user's username is included, so that invoice data may be recovered by the central server by searching for the username. Typically, this will not change very often between orders. Secondly, the cookie contains a unique identifier number which is dynamically allocated each time a user logs in.

The cookie is set to expire after a given time, to create a log-out function. In particular, the cookie is set to expire after 20 minutes. Thus, after a user has not requested further information from the central server 10 after 20 minutes, the cookie assumes that it is no longer needed and deletes itself from the web browser on the first client 40.

From the two pieces of information stored in the cookie, the central server can track the user's invoice, delivery requirements and order. However, if the cookie should be obtained by an unauthorized third party, it will be meaningless as all it indicates is the list of suppliers searched and their trade account numbers (but not trade account passwords) along with a username and number.

Cookies are also employed to allow trade prices to be displayed when a user has a trade account with a given supplier. This information is entered by the user and stored for future reference on the central database structure 20, prior to the commencement of a purchasing session. For each supplier with whom the user has a trade account, a separate cookie is transferred to the user's browser and each such cookie contains a variable name and value. The variable name employed in this embodiment is representative of the supplier's identity (e. g.'supplierone') and the value is'yes'if retail prices are to be displayed, but is

' < trade account number > 'if that user has a trade account and trade account prices are to be displayed.

A separate database within the central database structure 20 stores other user information which is too large or too sensitive to be stored in the cookie, such as invoice details for example. At least one file is provided as well, which contains information on the products to be purchased (the"shopping cart"). A further file may be provided as well, to those users who have a trade account, and this file is encrypted.

The file representing the shopping cart is checked by a small program, running on the central server 10, each hour and any such files which have not been altered for two weeks are deleted to free up space on the local database structure 20. Trade account information is, by contrast, maintained for several months before being deleted. Trade account information is highly sensitive and so is encrypted when stored in the central database structure.

Currently, the Blowfish (rnl algorithm is preferred although the specific encryption algorithm is stored in a library and may therefore be readily upgraded as appropriate.

Once a potential customer is successfully logged onto the server, he is presented with a menu such as is shown upon the left-hand side of Figure 2. This menu, labelled'Menu 1', is the top level menu from which a selection of general categories of building/construction material are available. The general categories for this application are selected in accordance with architectural considerations, and more specifically, the logical sequence in which materials are typically required for building projects.

In the example in Figure 2, the user selects the

general category'Concrete Work'and, using his mouse, clicks upon the'+'adjacent to the words'Concrete Work'. This opens the next branch on the tree of the menu structure, and lists a plurality of subcategories, such as'Cements & Aggregates','Concrete Admixtures'and so forth, as shown in Figure 2, Menu 2. The sequence continues with the user selecting the desired sub-category to open a third menu, Menu 3, with further, yet more specific categories of materials such as'Portland Cements'being offered.

Once a'.'is indicated next to a line of identifying text, it indicates that that is the lowest level of

categorisation of the product. Thus, in Menu 3, no further sub-divisions of'High Alumina Cement'are available. Finally in Figure 2, the user selects 'Portland Cements'from Menu 3 to display the various

types of Portland Cement available, namely'Ordinary Portland 25 Kg','Masonry Cement 25 Kg','White Cement 25 Kg', or'Small Bag 3 Kg'.

Having identified the specific product of interest by following through the menu structure to the lowest branch, the user is next invited to identify a limited number of suppliers from whom quotes for that product are desired. In one embodiment, the user may be invited to specify the suppliers by name. In a second embodiment, the user is instead requested to identify the geographical location which is of interest (for example, any suppliers within a five mile radius of the building/construction work to be carried out). By default, five suppliers are chosen, as this has been found to provide an optimum compromise between speed of supply of information to the user and a suitable range of quotes.

Once the number of suppliers has been determined, the product and price as supplied from the selected suppliers to the central database structure 20 is displayed to the user. In one embodiment, each of the various criteria supplied to the database is displayed and the user selects which he wishes to purchase on the basis of whichever criterion he chooses. For example, the user may see a list of ordinary Portland cement in supplier order, with an indication of the price per bag, delivery time, delivery cost, availability and so forth all displayed. In the preferred embodiment, however, and as shown in Figure 3, the available products are displayed in price order with the cheapest first. Here, it is seen that supplier 2 is able to offer a 25 Kg bag of

Ordinary Portland Cement at a lower price than the other suppliers. It will also be noted that the inventory code, input to the central database structure 20 by supplier 2, is displayed as well.

The user next adds the chosen product from the selected supplier to his shopping cart file by inserting the quantity of bags (in this case) which he wishes to purchase in the box 200 and then clicking on the'basket'icon 210 (Figure 3). If further information on a product is required, then the user

may select the'I'icon 215. The user may add further items to his shopping cart by reverting to the menu once more and collapsing it if necessary depending upon the category of the product he is looking for.

The same procedure for purchasing other materials is then repeated.

Figure 4 shows the contents of a user's shopping cart having chosen to purchase three products. It will be seen that the shopping cart is displayed in supplier order, with each material itemised together with its price. Once all items of interest have been added to the shopping cart, the'check-out'icon towards the bottom of the screen in Figure 4 is selected, which opens a further dialogue screen on the client 40, as shown in Figure 5a. The customer enters an invoice and a delivery address, and selects the preferred delivery date.

As previously explained, one of the two files stored in the central database structure 20 for a particular user relates that user's name to trade information. Thus, the central server 10 is able to advise the customer, at the remote client, that he has trade accounts with, in the present example, supplier 1 and supplier 3, and this is shown in the centre of Figure Sa. The customer then has the option either to pay on account, or to pay by entering credit card details as shown at the bottom of Figure 5a.

Once the payment details have been entered, the page at the remote client 40 is returned to the central server 10 which processes the received information. All payment details are sent over a secure connection using 128 Bit encryption from Verisign. For security reasons, it is preferred that no payment details are stored at the central server 10 but are instead forwarded immediately to the suppliers'servers (in this case, the server 90 of supplier 1 and the server 94 of supplier 3) for them to process the information themselves. Again, this is carried out using a secure connection with encryption.

Assuming that the stock is available, each relevant supplier server returns an acknowledgement to the central server 10 which forwards this to the remote client 40. A typical screen shot of the acknowledgement page forwarded to the client 40 is shown in Figure 5b. The final stage is for the customer to select the'buy'icon, shown in Figure 5b, which causes the transaction to be completed.

Having described the principles of operation of the system, a more detailed description of the software employed to carry out the method of the invention will now be set out.

It will be noted, particularly from Figure 2, that, in contrast with traditional web sites, pop-up windows are not employed in the preferred embodiment.

Instead, multilayer frames are provided within the web browser at the remote client. It has been found that the use of multilayer frames, generated by an applet running on the client rather than across the Internet from the central server 10, provides for significantly quicker navigation through the menus. In the preferred embodiment, there may be up to seven levels in the menu structure, with potentially several tens or even more of specific building/construction materials or categories of such materials in each

level. These can be expanded or contracted by the central server administrator as appropriate. To achieve this rapid navigation, the menus themselves, along with the contents of the central database structure 20 relating to the products and their suppliers, are sent as a zipped Java applet, preferably compatible with Java Version 1.1. 4. To simplify programming and maintenance, the menu structure is written incorporating Object Oriented techniques. Each object is a separate file so that the compiled menu is in fact, in the preferred embodiments, seven separate files, one of which (the database) is potentially extremely large (certainly in excess of 100 KB). In order to reduce the download time between the client and server of these files, Java JAR technology is employed. This groups multiple files into a single file and at the same time compresses them using a"zip"algorithm. Using this technique, the complete menu system is available to be downloaded from the central server 10 to one of the remote clients as a single 40 KB file. This file also contains suitable graphics for the menus.

Traditionally, when building a"shopping cart" for a web site, Object Orientated Programming techniques are used, usually because the code thus produced is relatively easy to follow. Once a potential customer has logged onto the central server 10 from a remote client, most subsequent actions at the central server will require access to the shopping cart file, which is stored at the central database structure 20 as explained above. The shopping cart file needs to be read and sorted once accessed. The traditional approach, as a customer browses around a web site, is to place items selected for purchase and place them into an object.

The drawback with this technique is that it is relatively slow to execute, because of the length of

the file thus produced. In the presently preferred embodiment, by contrast, each item selected for purchase is instead placed into an array. These arrays are arranged so that the items are naturally grouped by supplier. Typically, generating an array involves the addition of one line of code to the shopping cart file, as opposed to ten lines which would be necessary to create objects.

This technique has several advantages. In addition to increased speed of execution, the code itself is by no means as easy to follow. This is of benefit should a malicious user ever manage to access the code.

As an example, if a customer wishes to purchase a specific product from, say, supplier 1, then if object oriented programming techniques were employed, the objec might look like: Mycart. items. supplierone. item3. name.

An array, by contrast, is much simpler yet still provides the same information to the central server: $orders [3] [2] the numerals 3 and 2 are the elements (that is, 3 across and 2 down) of a spreadsheet. It is relatively straightforward to add further elements to the array (e. g. $orders [2] [1]) as matters become more complex.

The foregoing description of the preferred method has explained how information from various suppliers that is stored on the central database structure 20 is provided to potential customers at remote clients to permit comparison of various parameters and select and purchase building/construction materials. As previously explained, the central database structure 20 has a plurality of separate databases, each accessible only by a respective supplier who maintains information of available materials at any time along with their prices and so forth. This technique is advantageous in that the database information can all be zipped together with the menu structure and sent as

a Java applet, as set out above, which allows rapid searching of the database at the remote client. The problem, however, is that it is only really feasible for a supplier to maintain a single list of prices for the products or materials that he offers on the central database, or he would spend inordinate amounts of time updating his database on the central database structure 20. For example, building contractors may well be offered trade discounts and, for very large contractors, these discounts may be significant. The discount may also depend upon the quantity of a particular material being purchased.

It is for these reasons that the system of Figure 1 provides access to the databases of the various suppliers. Likewise, a potential customer may receive information from the central database structure 20 and subsequently require further information from a particular supplier which is not stored on the central database structure 20.

The central server 10 is designed to connect to potentially thousands of suppliers'servers, whatever the type of server. Potentially, if every supplier server was different, then the program resident upon the central server 10 would need to include code to connect to each and every single server.

Realistically, this would produce an enormous program which would take a very long time to execute. In fact, each user only usually requires to connect to perhaps five servers, for the five suppliers of interest.

Thus, most of the very large program would not be required on a per user basis.

The present invention, in the preferred embodiment, solves this problem through the creation of libraries of executable code resident upon the central server 10. Each user who logs onto the central server 10 has their own, individual, PHP program running on the remote client. Thus, if ten users are

separately connected to the central server 10 via ten separate remote clients, then ten copies of that PHP program will be running. Each individual copy of the PHP program may be streamlined for the specific user's requirements. Thus, for example, if a user wishes to obtain a quote from supplier 1, supplier 3 and supplier 4, the program, when executed, loads the required software to connect to supplier servers 90, 94 and 96, and only to these servers. At the same time, another user's PHP program, running on a separate client, may only wish to connect to supplier servers for supplier 2 and supplier 4, and thus will have different requirements. PHP is favoured over, say Active Server Pages (ASP) because it is more flexible in terms of the databases to which it may connect. It is also an order of magnitude faster.

The central server 10 maintains three separate libraries for each supplier, one to obtain a quote, one to check stock, and one actually to place an order. Thus, each program is streamlined in accordance with the connection requirements to the appropriate supplier servers, with the complexity of the program increasing only with the complexity demanded by the user.

It is for this reason that the information supplied to a user at the remote client defaults to five suppliers for optimised searching. It has been discovered that, once it becomes necessary to connect via the central server to more than five supplier servers, the system begins to slow down. It will be understood that the system does not preclude access to more than five supplier serves at once, but that this does introduce noticeable delays.

Once the required request for connection to the suppliers'databases has been made by the remote client and the resultant page of information has been received at the remote client (all of this occurring

via the central server 10), the software deletes itself. When the user requests a further page, the relevant program runs (again, one per user). This time, separate libraries may be accessed as necessary.

The plurality of transaction servers 50-58, local to the central server 10, are provided to prevent malicious attacks in the form of malicious multiple requests to the various suppliers leading to denial of service. Without some form of precaution, it would otherwise be possible physically to prevent a supplier from taking orders, either via the central server 10 or indeed from direct contact by telephone or the like.

As the number of suppliers using the central server 10 increases, so will the number of transaction servers. Each transaction server receives a request from a remote client, checks its validity and carries out other security procedures. The request is then forwarded to the relevant intermediary server 70-80 at the premises of the supplier of interest. Each intermediary server also performs several checks before forwarding the request to the supplier server 90-100. Each intermediary server prepares the request for the corresponding supplier server, by, for example, removing any extraneous data which the request may have accumulated following transmission from the remote client. Importantly, the servers prevent any system other than the central server 10 from reaching the supplier server, and this is assisted by the use of private line connections 130-136.

The central server 10 is programmed to monitor traffic between the intermediary and transaction servers, so that, if necessary, requests to a particular supplier's server may be blocked if that server is experiencing difficulty with current demand levels. In such a situation, that particular supplier

server reverts to serving only local queries to it from the supplier's LAN, for example. This permits the supplier to continue trading as normal. Once the load upon the supplier's server reduces, then it may be reconnected to the network shown in Figure 1.

The particular arrangement of Figure 1, using intermediary and transaction serves maintains the integrity and security of the supplier servers, which is deemed to be of even more importance than the security of the central server 10. The particular arrangement, including the use of private line connections, prevents any possibility of hacking of supplier servers via the central server 10. Indeed, the described arrangement even prevents hacking by an administrator of the central server 10.

The software operated by the intermediary servers in the preferred embodiment employs a mixture of programming languages. Connections from one of the transaction servers to one of the intermediary servers is currently envisaged to be accepted using a customised version of apache web server, which does not listen on port 80 as would usually be done. The security software mentioned above is written in PHP and communicates with a Visual Basic Application which conducts the communication between the intermediary server and the respective supplier server. As with the central server 10, multiple copies of the PHP software may exist to cope with several requests from separate potential customers. It will be understood that, should the supplier alter the supplier database 110-120 which he uses, then the intermediary server must be altered to cope with this.

Turning finally to Figure 6, a database structure for the central database structure 20 is shown. Each individual block 300 is intended to represent a single element within the database structure. According to a particularly preferred feature of the invention, the

database is arranged as a"pocketee'structure, as shown. This allows searching to be accomplished substantially more quickly than a standard, multidimensional relational database.

In particular, the database is arranged such that the most general categories of materials are placed in separate pockets. In the example of Figure 2, Menu 1, there are sixteen general categories in the top level menu, and the database would thus be divided into sixteen separate pockets 310. Each pocket 310 may in turn be sub-divided into sub-pockets 320 into which sub-categories (such as are displayed in Menu 2, Figure 2) are stored. Yet smaller sub-pockets 330 may be employed for the level of category below that, and so forth.

It will be seen from Figure 6 that the various pocket sizes do not need to be the same.

The advantage of this structure for the present application is that it dramatically increases the speed at which the database may be searched. In essence, by using sixteen pockets, sixteen separate databases are formed instead of one extremely large database. The particular material of interest is located in one of the pockets and it is simply necessary to index that material to the relevant pocket and sub-pocket if necessary. Referring again to the example in Figure 2, a 25 Kg bag of ordinary Portland cement may be indexed in the database as [1, l, l, ABCD] where the numerals indicate the pocket relating to concrete work, the sub-pocket relating to cements and aggregates, the sub-sub-pocket relating to Portland cements and the characters A B C D index the relevant information within the smallest pocket.

In order to store information in the correct pocket of the database, it is necessary initially that the product from a given supplier is categorized manually. In other words, when a supplier decides to

provide information accessible from the central database structure 20, he must enter information regarding each product into the correct category himself, and the database structure then stores the product in the appropriate pocket. Preferably, a category structure exists, so that the supplier is prompted by the central server with a menu similar to that shown in Figure 2 to help him categorize his products correctly.

This process only needs to be carried out whilst the supplier is initially setting up his database on the central database structure 20, and if he subsequently wishes to add new products to the list of those products he offers. Products about which information has been stored already are given a product ID that is unique at least for their supplier.

The product ID allows the category structure to be maintained even when there is no data stored in it, and to allow prices to be updated easily.

Although one specific, preferred embodiment of the invention has been described, it will be understood that various modifications and additions to the system may be contemplated without departing from the scope of invention, which is defined in the attached claims.

For example, rather than searching via the menu structure, the data forwarded to the web browser of the remote client may be searched using a keyword search rather than drilling down through menus. Means for permitting data entry to carry out a keyword search are shown towards the top of Figure 3.

Furthermore, in addition to manual updating of the central database structure 20 by the various suppliers, the system may be configured automatically to connect to suppliers'servers, using the preferred structure of transaction and intermediary servers, to permit that particularly supplier's information stored in the central database to be updated without manual input being necessary. Typically, the server would make this connection overnight whilst the supplier himself is unlikely to be placing much load on the supplier server.

Claims

CLAIMS :

1. A method of facilitating the purchase of building/construction materials, comprising the steps of: storing on data storage means, for each of a plurality of suppliers of building/construction materials, at least one purchasing parameter set including at least one purchasing parameter selected from the list comprising availability, physical proximity, delivery time, and price, and relating to one or more specific building/construction materials; accessing, from a remote location, the said data storage means, via a central server in communication with the said data storage means ; obtaining, at the remote location, an array of information including the or each purchasing parameter set supplied by the plurality of suppliers and relating to at least one of the specific materials; and comparing, at the remote location, equivalent purchasing parameters, provided by different suppliers for a given specific material, and obtained from the data storage means via the central server, so as to allow purchase of that given specific material from the supplier or those suppliers for which one or more purchasing parameters in a purchasing parameter set are considered most favourable.

2. The method of claim 1, in which the data storage means includes a database local to the central server.

3. The method of claim 1 or claim 2, in which the data storage means comprises a plurality of separate databases, each of which is local to a corresponding one of the plurality of suppliers, the

method further comprising the step of routing access to the plurality of separate databases via the central server.

4. The method of claim 2 or claim 3, further comprising: displaying, at the remote location, a menu of a plurality of different building/construction materials; selecting from that menu, at the remote location, a specific one of the different building/construction materials; and displaying at the remote location the purchasing parameter set supplied by the plurality of suppliers and relating to the specific material selected from the menu.

5. The method of claim 4, in which the menu is presented as a hierarchical structure, the method further comprising: selecting at the remote location and from a top level menu, a general category of building/construction materials of interest from a range of available categories; displaying a range of specific materials each belonging to the selected general category; and selecting the given specific material from the range of specific materials so as to permit the said step of comparing the equivalent purchasing parameters for that given specific material.

6. The method of claim 4, in which the menu is presented as a hierarchical structure, the method further comprising: selecting, at the remote location and from a top level menu, a general category of building/construction materials of general interest from a range of

categories ; displaying a lower level menu of sub-categories of building/construction materials relating to the selected general category in the top level menu; selecting, from the lower level menu, a subcategory of building/construction materials of interest; displaying a range of specific materials each belonging to the selected sub-category previously displayed as part of the lower level menu; and selecting the given specific material of interest from the range of specific materials so as to permit the said step of comparing the equivalent purchasing parameters for that given specific material.

7. The method of claim 4, in which the menu is presented as a hierarchical structure, the method further comprising: selecting, at the remote location and from a top level menu, a general category of building/construction materials of interest from a range of available categories; displaying, consecutively and in accordance with user selection, a plurality of lower level menus of increasingly specific sub-categories of building/construction materials relating to the selected category in the top-level menu; displaying a range of specific materials each belonging to the most specific of the user selected sub-categories previously displayed in the lowest of the plurality of lower level menus; and selecting the given specific material of interest from the range of specific materials so as to permit the said step of comparing the equivalent purchasing parameters for that given specific material.

8. The method of any one of claims 4 to 7, in

which the or each menu is stored at the central server as a menu data file, the method further comprising : compressing the or each menu data file at the central server before forwarding it or them from the central server to the remote location.

9. The method of any one of claims 4 to 8 when dependent upon claim 2, further comprising compressing the contents of the database local to the central server and forwarding the compressed contents from the central server to the remote location.

10. The method of claim 7 when dependent upon claim 2, in which each menu is stored at the server as a corresponding menu data file, the method further comprising : compressing the top level menu data file and each of the plurality of lower level menu data files; compressing the contents of the database local to the central server; forming a composite file from the compressed menu data file and database contents ; and forwarding the said composite file from the central server to the remote location.

11. The method of claim 8, claim 9 or claim 10, further comprising: encrypting the or each file before forwarding it or them from the central server to the remote location.

12. The method of any preceding claim, in which the array of information is stored in a multidimensional relational database, the method further comprising: dividing the database into a plurality of pockets, each pocket being chosen in accordance with

an appropriate corresponding general category of building/construction materials ; allocating each specific building/construction material to one of the plurality of pockets within the said multidimensional database in accordance with the chosen appropriate general category ; and storing an identifier for each specific building/construction material so allocated in the database, along with the or each purchasing parameter associated with that specific building/construction material.

13. The method of claim 12, in which, in a particular database pocket, each specific building/construction material is allocated in the database to a chosen one of a further plurality of sub-pockets containing data on sub-categories of building/construction materials, each sub-category being more specific than the general category to which it belongs.

14. The method of any of claims 5,6, 7,12 or 13, in which the general categories are selected in accordance with the architectural design and build process for a property.

15. The method of any preceding claim, further comprising storing information relating to each of a plurality of suppliers of building/construction materials.

16. The method of claim 15, in which the information relating to each supplier is stored in a separate database that is local to the central server and is remotely accessible by the corresponding supplier.

17. The method of claim 3, further comprising : providing a library of software applications, each application, when executed, permitting the routing of a request from the remote user to at least one of the plurality of suppliers.

18. The method of claim 17, in which the step of accessing the said data storage means from the said remote location includes the steps of: accessing the central server from the remote location; identifying the specific material for which the said purchasing parameter set is to be obtained; selecting from the library of software applications, those applications which when executed will permit routing of a request from the remote user only to a selected subset of the totality of available suppliers; executing those selected software applications in response to a request, from the remote location, for information from one or more of the chosen subset of suppliers; and connecting the central server to the database that is local to the or each supplier in the chosen subset, so as to permit the said array of information to be obtained.

The method of claim 18, in which the or each of the chosen subset of suppliers has a supplier server remote from the central server, and the central server is in communication with a plurality of transaction servers local thereto, the step of accessing the said storage means comprising: routing a request for information regarding a specific building/construction material from a remote location, via the central server, to one of the transaction servers;

validating the said request at that transaction server ; securely connecting between the said transaction server and the remote supplier server; and routing the request to the said remote supplier server.

20. The method of any preceding claim, further comprising, after the step of comparing at the remote location, the step of: sending a request from the remote location to the central server to purchase materials from that supplier whose purchasing parameters are considered most favourable.

21. A computer system for facilitating the purchase of building/construction materials, comprising: a data storage means, upon which is stored at lest one purchasing parameter set including at least one purchasing parameter selected from the list comprising availability, physical proximity, delivery time, and price, for each of a plurality of suppliers of building/construction materials, and relating to one or more specific building/construction materials; and a central server in communication with the data storage means, the central server being configured to receive a request from a remote user for information from a purchasing parameter set and relating to building/construction materials; to access the data storage means, and to forward to the remote user an array of information including the or each purchasing parameter set supplied by the plurality of suppliers and relating to at least one of the specific materials; whereby the equivalent purchasing parameters

provided by different suppliers for a given specific material may be compared at the remote location so as to permit purchase of that given specific material from the supplier for which one or more purchasing parameters in a purchasing parameter set are considered most favourable.

22. The system of claim 21, further comprising at least one remote terminal configured to receive one or more files from the server in response to a request made by the or each remote terminal for information.

23. The system of claim 21 or claim 22, in which the data storage means is a relational database divided into a plurality of pockets, the or each purchasing parameter set for a supplier being stored in a particular one of the pockets in the database in accordance with a category of building/construction materials to which the associated particular building/construction material belongs.

24. The system of claim 23, in which the data storage means is local to the central server.

25. The system of claim 21 or claim 22, further comprising a plurality of transaction servers, arranged locally to the central server, and a plurality of supplier servers each local to the data storage means which comprises a database of building/construction materials for a corresponding supplier of such materials, each transaction server being configured to forward from the central server and, on request from the remote user, a request for information to one or more of the supplier servers, so as to cause the said array of information to be forwarded, in response, to the remote user.

26. The system of claim 25, in which the server has access to a library of software routines each of which is operable, when executed, to cause connection of the central server, via at least one of the transaction servers, to a respective one of the supplier servers to in turn allow access.

27. A computer program product comprising program elements which, when executed upon the central server, cause the method of any of claims 1 to 20 to be carried out.

28. A server loaded with the computer program product of claim 27.

29. A method of facilitating the purchase of building/construction materials substantially as herein described with reference to the accompanying drawings.

30. A computer system substantially as herein described with reference to and as shown in the accompanying drawings.