DATA EXCHANGE SYSTEM FOR E-COMMERCE
Field of the Invention
This invention relates to the implementation of electronic data exchange, particularly but not exclusively to a distributed e-commerce platform for business- to-business electronic commerce services.
Background
Although electronic commerce, commonly referred to as e-commerce, has become prominent with the spread of the Internet, electronic commerce systems have existed since the advent of computers, when they were generally referred to as systems for Electronic Data Interchange (EDI). Figures la to Id illustrate a number of conventional EDI models.
Figure la illustrates the principle of direct EDI transmission, which is the preferred communication platform for business partners to exchange data and information. This method of communication requires business partners 1, 2 to use similar computer platforms and is therefore not viable in today's global trading environment, being limited to application in a Wide- Area Network (WAN) environment.
Figure lb illustrates a typical Internet Web-enabled e-commerce system. A supplier 3 provides a web page hosted on a web server 4 which allows buyers 5, 6 to log-in via the Internet 7 using conventional web browser software, to access functions such as data entry of orders and enquiries. The data remains with the supplier and there is no connection between any of the buyers.
Figure lc illustrates a conventional EDI system using VANs (Value Added Network) service providers. Conventional EDI was conceived about 20 years ago to overcome the prohibitively high cost of using similar computer platforms between trading partners, as described in relation to Figure la above. Instead of using similar computer platforms, conventional EDI involves structuring the data into standard structured formats such as UN/EDI-Fact, Ansi X.12 and so on.
Conventional EDI involves the interchange of structured data according to agreed message standards between computers systems, by electronic means. Intermediaries such as the VANs provide the communication medium to enable the electronic transmission of business documents between a large number of different organisations.
At its core, a VAN 8 is essentially an electronic post office. It receives electronic messages, which may be orders, invoices, etc., from a first organisation 9, reads the addressing information contained in the EDI envelope surrounding these messages and posts them into the mailboxes 10, 11 of the respective recipients 12, 13.
However, conventional EDI systems remain expensive and hence have a limited user base, as most small and medium sized companies continue to opt for manual interchange of data. The overheads and time required in educating staff and enticing trading partners to set up EDI systems tend to outweighs their benefits.
Figure Id illustrates a Web based EDI solution, in which EDI services are provided by a third party portal 14 via the Internet 15. The portal 14 typically uses the FTP protocol to transfer business document files in any given structured format from a sender 16 to the portal server 17. The server reads the addressing information, sorts and posts the documents to the respective recipient's 18, 19 mailboxes 20, 21 within the same server 17. The portal administrator 22 then sends e-mail alerts to the recipients 18, 19, at scheduled intervals, informing them to browse incoming documents now residing at the portal 14.
However, this solution lacks the direct, real-time and interactive electronic data interchange functions that are essential in today's highly competitive and time sensitive business environment when information is required instantaneously to facilitate planning and decision-making. Furthermore, since data resides at a third party portal, data security is a serious concern.
In all of the above cases, the VAN, portal or exchange act as servers which cannot send information to clients, but rather wait for clients to connect to them. Therefore, clients cannot send messages or perform transactions directly with other clients, but have to route messages through the server, and then wait for a response, which can take anything from several minutes to days.
Summary of the Invention
According to the present invention, there is provided a system for implementing electronic data exchange between a plurality of users, comprising a plurality of gateway server machines, each located at a user's premises, for storing data associated with their respective users, and a hub server machine for enabling data exchange between the gateway server machines via a data communications network, wherein data is transmitted between selected ones of the gateway server machines without intermediate storage at the hub server machine.
By storing data at a user's premises, security is enhanced. The data can be sent point-to-point between subscribers to the data exchange service, with no need for intermediate storage at the hub server machine, so providing a bi-directional, fully interactive, direct and real-time infrastructure for conducting e-commerce transactions. Any client can send messages or perform transactions directly with any other client. The resultant streamlining of supply chain processes and back-office applications permits significant cost savings to be achieved.
According to the present invention, there is further provided a hub server for enabling data exchange between a plurality of gateway servers over a data communications network, comprising means arranged to maintain connection information for each of the plurality of gateway servers, means arranged to receive a request from a first gateway server for connection information for a second gateway server, and means arranged to transmit said connection information to said first gateway server, whereby said first gateway server can establish a route from itself to the second gateway server which does not include the hub server.
The hub server can further comprise means arranged to receive a request from the second gateway server to authenticate the first gateway server. When the second gateway server receives a connection request from the first gateway server, it can use the hub server to determine whether the first gateway server is an authorised server. The requisite information can alternatively be downloaded from the hub server to the second gateway server periodically, so that it does not need to contact the hub server when it receives a connection request.
The invention further provides a gateway server machine for implementing electronic data exchange between a plurality of users, said gateway server machine being located at a user's premises, comprising means for storing data associated with the user, means for connecting to a further gateway server machine located at the premises of a further user, and means for connecting to a remote hub server machine to obtain information for enabling data exchange between the gateway server machine and the further gateway server machine via a data communications network, wherein the gateway server machine is configured to use the enabling information to bypass the hub server machine and connect directly to the further gateway server machine.
According to the invention, there is also provided a method of implementing data exchange between first and second gateway servers, each of said servers being located at the premises of a user, comprising connecting the first gateway server to a remote hub server to receive authorisation to transfer data to the second gateway server, and in response to said authorisation, connecting the first gateway server directly to the second gateway server for data transfer. The requisite information can alternatively be downloaded from the hub server to the first gateway server periodically, so that it does not need to contact the hub server when it wishes to connect to the second gateway server.
Brief Description of the Drawings
Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:
Figure la is a schematic diagram illustrating the principles of conventional direct
EDI transmission;
Figure lb is a schematic diagram illustrating a typical Internet Web-enabled e- commerce system; Figure lc is a schematic diagram illustrating a conventional EDI system using third party value added networks (VANs);
Figure Id is a schematic diagram illustrating a conventional Web based EDI solution;
Figure 2 is a schematic diagram illustrating a data exchange system according to the invention;
Figure 3 is a schematic diagram illustrating a typical conventional server structure;
Figure 4 is a flow diagram illustrating the operation of the system of Figure 2;
Figure 5 is a schematic diagram illustrating a further example of a data exchange system according to the invention; and Figure 6 is a flow diagram illustrating the processing performed by the system of
Figure 5.
Detailed Description
Referring to Figure 2, a system for providing a data exchange service according to the invention comprises a plurality of application server machines referred to herein as gateway servers or gateways 25, 26, 27, 28, each connected to the Internet 29, via various connecting methods, such as lease line, ISDN dial-up, and a plurality of application servers referred to herein as hub servers or hubs 30, 31, 32, 33, also connected to the Internet 29. Each gateway 25, 26, 27, 28 is, for example, a low entry cost application server located at an organisation's business premises 34, 35 and which can further be easily connected to the organisation's back office systems 36, 37.
Each of the gateway servers 25, 26, 27, 28 is associated with data storage capacity, for example databases 38, 39, 40, 41 for storing data locally, ie. at the organisation's premises 34, 35 rather than centrally.
Each of the hubs 30, 31, 32, 33 is for example an application server machine located at the premises of the provider of the e-commerce service, as well as at selected internet service providers (ISPs). For example, a hub server is located in each major city throughout the world to provide local routing and dial up services.
The application server machines mentioned above are, for example, commercially available server machines such as members of the Dell™ Poweredge™ server series running an appropriate operating system such as Microsoft Windows NT™ or Linux. Such servers typically comprise the components which are shown schematically in Figure 3. It will nevertheless be understood that the described configuration is not limiting and other components and configurations are possible. It will further be understood that the application servers run the appropriate application software to perform the functions necessary to support the system according to the invention. For example, the gateway and hub servers run Apache™ web-server software to provide web pages for access over the Internet.
Referring to Figure 3, a server machine 25, 26, 27, 28, 30, 31, 32, 33 comprises a central processing unit (CPU) 45 for executing computer programs and managing and controlling the operation of the computer. The CPU 45 is connected to a number of devices via a bus 46,- the devices including a read/write device 47, for example a floppy disk drive for reading and writing data and computer programs to and from a removable storage medium such as a floppy disk 48, a storage device 49, for example a hard disk drive for storing system and application software, a CD- ROM drive 50 and memory devices including ROM 51 and RAM 52. The computer further includes user input/output devices, such as a mouse 53, keyboard 54 and display 55.
The operation of the system shown in Figure 2 will now be described with reference to Figure 4. When a customer 34 wishes to exchange information with another organisation, for example, a supplier 35 which is also a subscriber to the data exchange service, the customer 34 uses application software running on his gateway server 25 to request an appropriate service. For example, any gateway server 25, 26, 27, 28 can execute a number of different modules including a request for quotations
(RFQ) module, purchase order management and processing module, order acknowledgement and confirmation, invoicing, auction and e-payment modules.
For example, the customer 34 runs the RFQ module on his gateway server 25 which provides a web browser interface, for example, Microsoft Internet Explorer™ to the user (step si). The customer prepares the data that he requires from the supplier in accordance with the requirements of his particular industry. For example, he enters a desired item, such as a make and model of an integrated circuit, or selects it from a pre-existing list (step s2). He also selects one or more suppliers from a list, or this is done automatically based on the category of the item selected, for example the category of semiconductors (step s3). The list of suppliers who subscribe to the system is periodically downloaded from the hub server to the customer's gateway.
The customer then clicks on a "Send" button within the browser to initiate the data transfer (step s4). In response, the gateway attempts to connect to the hub server 31 (step s5). A firewall (not shown) is one level of security provided at the hub 31 to ensure that only authorised organisations can access the website. Further security is provided by the customer 34 only being able to log-in by correctly entering his username and password (step s6). The supplier details are then downloaded to the customer gateway (step s7). To speed up the query procedure, this data can be periodically downloaded and cached at the customer gateway until an expiry period has lapsed, for example every 3 days.
Once the customer has the suppliers' URLs and configuration information, it attempts to establish a secure connection over the Internet (step s8), for example using open-platform technology such as SSL. A server-side module at the supplier connects to the hub (step s9) and queries the customer gateway authenticity as well as any other data necessary for verification of the customer, such as the digital signature of the digital certificate used and any additional password assigned to the customer (step slO). The hub then authorises the sending of data between customer and supplier (step sll). As with the supplier data, the customer data be cached on the supplier gateway ttntil an expiry period lapses.
Assuming that both customer and supplier are authorised to carry out the transaction, data transmission then takes place between the customer and supplier gateways, as described below. The customer gateway 25 encrypts the data to be sent using an appropriate encryption algorithm at the customer's premises 34 (step sl2) and sends the encrypted data over the Internet directly to the supplier 35 over a secure connection (step sl3). Receipt of the data (step sl4) at the supplier gateway triggers an alert to the supplier, for example in the form of e-mail, fax or a print-out (step sl5). The supplier can then view the customer's RFQ record on a screen and respond accordingly via the gateway, in a similar manner to that described above (step sl6). Data is not stored at the hub, whose main function is to ensure that both senders and recipients of the data are authorised and registered users of the e- commerce services provided by the hub.
The hub also monitors transactions occurring between customers and suppliers. When the customer gateway sends a message, it logs the message size (step s20) before or after the message has been sent. The hub periodically receives the message log from customer gateways for billing/ monitoring purposes (step s21). The supplier gateway similarly maintain logs of received messages to be sent to the hub (step s22).
The customer and supplier gateways can perform further processing on the stored data. For example, when a supplier gateway receives a purchase order, it can check locally stored data to ensure product availability, for example by initiating interaction with back-end databases.
Referring to Figures 5 and 6, in a further example application of the system according to the invention, the Head office 50 of an organisation wants consolidated figures (inventory/ financial/WIP) from outlets 51, 52, 53. This is especially useful for, for example, logistics companies to track deliveries, restaurant headquarters to track outlet stock and manufacturers/distributors to track worldwide sub-contract repair centres' work-in-progress.
The gateway 54 at the Head Office broadcasts the request to the outlets' gateways 55, 56, 57 (step s30) in accordance with the procedures detailed above, with authority and connection details for the connection to the outlets being provided by the hub 58 (step s31). The gateways 55, 56, 57 at each outlet obtain connection authority from the hub (step s32) and will then reply automatically directly to the head office gateway 54 (step s33) by examining their respective databases 59, 60, 61. The gateway 54 at the Head Office consolidates the responses and presents them on screen or by report (step s34).
Those skilled in the art will recognise that the foregoing description has been presented for the sake of illustration only. As such, it is not intended to be exhaustive and other embodiments are envisaged which fall within the spirit and scope of the invention as defined in the appended claims.