AU2418600A - Software application for enbaling financial transactions over the internet - Google Patents

Description

2 o

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION STANDARD PATENT SOFTWARE APPLICATION FOR ENABLING FINANCIAL TRANSACTIONS OVER THE INTERNET The following statement is a full description of this invention: This invention relates to a computer software application that promotes and enables secure, efficient and "user-friendly" financial transactions to occur between a customer and a merchant on the Internet, without the transmission of the customers' sensitive financial information at any time within the process.

The effectiveness and growth of Customer-Merchant commerce on the Internet is severely hampered by a number of issues peculiar to the nature of performing electronic financial transactions. A Real World financial transaction between a customer and merchant usually involves the customer presenting some tangible instrument of exchange, such as cash, cheque or credit card. In return, the merchant provides the goods or service and a receipt to indicate the transaction has occurred. This Real World customer-merchant economic activity can be broken into two forms, the "Cash Economy" and the "Cash-less Economy". Larger purchases tend to be Cash-less transactions using a Credit card or cheque. The credit card has grown in popularity because of its convenience and wide acceptance.

Customers and merchants do not have to carry large amounts of cash. Instant purchasing decisions can be made, and the fees incurred by the merchant in these transactions can be absorbed into the value of the sale.

For smaller purchases, Cash is the preferred instrument of exchange. It is more convenient for the customer and S 15 merchant, allowing a fast turnover in sales. Customers browsing through shopping malls often make many such small and often spontaneous purchases, and the fees associated with credit cards often become a significant dis-incentive to their use.

*o• The Internet, by its nature, is a Cash-less economy. Economic activity between customer and merchant has •20 evolved from the practices current in the Real World and the Credit card has become the defacto standard instrument of monetary exchange. The effect of this is that the whole Cash economy available in the Real World, with its attributes of speed, convenience and spontaneity, does not generally occur.

V.000 S.0. With the growth of credit card use, many customers have become used to providing their card details over the telephone inorder to make a purchase. Financial transactions based on the information printed on.the credit card and without reference to the card itself, have become common place. The customer has faith that their phone Sconversation is unlikely to be intercepted and that the person they are speaking to is a bone fide merchant who will not misuse the card information.

The ease with which purchases can be made in this way, without reference to the card itself, has resulted in a huge increase in fraudulent activity. A person in unauthorized possession of credit card details can rapidly strip the account of its assets up to the cards limit, which is often substantial.

On the Internet, the customer does not have the relative security provided by a point to point telephone line connection, and is less clear as to the identity of the merchant at the other end, when performing a credit card transaction. There is therefore a general reluctance to participate in financial transactions on the Internet.

To overcome these real and perceived security issues a number of different systems and technologies have been developed. Many protocols incorporating data encryption techniques have been described, including Secure transaction Technology Internet Keyed Payments Secure Electronic Payments Protocol ("SEPP") and Secure Electronic Transaction Netscape has developed a general purpose secure protocol, Secure Sockets Layer This has become the defacto standard protocol for secure communication between two computer systems, and is incorporated in all major Internet browser software today. Other such protocols include Private Communications Technology Pretty Good Privacy and Secure Hypertext Transport Protocol ("SHTTP") amongst others.

Besides providing a means of encrypting and de-encrypting sensitive data, secure protocol methodologies need to address the issue of identification of the parties and verification of the data in a transaction. If either party is not assured of the identity of the other, then they can not be assured they will receive their part of the exchange.

To overcome this problem, one or more of the parties may possess a Digital Certificate. This is an encrypted, unforgeable electronic document, signed by a trusted authority, that vouches for the identity of the holder. Using a combination of Message Digests, symmetric and asymmetric encryption techniques and trust in some authority that can vouch for the identity of a transaction partner, transaction security can be achieved. The downside of these techniques is the performance hit that results from the computationally intensive operations that are involved.

S °iThis invention addresses the issues of security of transactions, identity of the party making payments, and improving performance of such transactions.

DEFINITIONS USED IN THIS DOCUMENT: Internet Service provider (ISP): An organisation that provides access to the Internet, where a person would typically dial a telephone number and connect to its computer system, using it as a gateway to the Internet.

Hyper Text Markup Language (HTML): The standard method of displaying content on the Internet, by "marking up" text and graphics with tags that define how the content is to be presented.

Hyper Text Transport Protocol (HTTP): A computer protocol that handles the transmission of HTML and other documents on the Internet.

°File Transfer Protocol (FTP): A computer protocol that handles the error free transmission of a wide variety of files across the Internet. Typically used for distributing programs, music files and graphics.

Transmission Control Protocol, Internet protocol (TCP/IP): A suite of transmission protocols that underlay most other protocols on the Internet, providing the basis of the error free transmission of data.

Java Applet: A small application written in the Java programming language, that may be linked to an HTML document on the Internet. When the document is viewed, the Applet executes.

Web Page: An HTML document.

Client: A computer system typically a Personal Computer that accesses the Internet using an ISP as a gateway.

Merchant: A computer system on the Internet that has products for sale.

Key-Set: A set of electronic "keys" consisting of a Public Key and a Private Key that enables Public Key Cryptography. Information encrypted using one key can only be unencrypted using the other key in the pair.

Typically, the Public key is freely distributed, and the Private key is kept secret.. This allows for the secure transmission between one party and the owner of the private key.

Authentication: Proving to your satisfaction that a given party is who they say they are.

Secure Sockets Layer (SSL): A computer protocol that provides a secure encrypted connection between two parties.

KIS An acronym used to describe elements of the invention: KIS protocol: An application level protocol that is part of this invention, and provides a mechanism for implementing the transmission of messages between the parties involved in a financial transaction, using this invention.

KIS Authority: An organisation that is trusted by the merchant participating in a financial transaction using this invention, in that it confirms the identity of an ISP that the merchant wishes to deal with.

IP Address: A sequence of numbers used in the Internet Protocol (IP) that is unique for each object on the Intemrnet, and defines its location within the Intemrnet.

Cipher suite: A system of encoding data for security purposes.

Private Key Cryptography: A method of encrypting and de-encrypting data using Private (secret) keys.

BRIEF SUMMARY OF THE INVENTION The invention consists of an arbitrary number of software code modules that implement a method of providing secure financial transactions on the Intemrnet, as described below.

According to a broad aspect of the preferred embodiment of the invention, a client of an Internet Service Provider (ISP) browses to a merchant server site, downloads a Web page and a Java applet associated with that page. If the client selects product(s) for sale on the page, the applet communicates with a code module on the merchant server, S 20 sending the clients purchasing requirements and the clients' Internet address, and an Internet address provided by the

ISP.

If a database on the merchant system has no record of the authenticity of the ISP in relation to the provided S•Internet address, then the code module on the merchant server may communicate with a KIS Authority, requesting authentication of the ISP.

If the KIS authority authenticates the ISP, it provides the merchant the Public key associated with a key set possessed by the ISP. A code module on the merchant system communicates with a code module on the ISP server, using the address provided, and using an application-level protocol over a secure connection.

The merchant initiates the communication, and proposes an Agreement between it and the ISP, to facilitate financial transactions between the merchant and the client(s) of the ISP. The parameters of the proposed agreement are taken from a table of"Dollar Value of Business" and associated Fees. This sets the volume of business to be undertaken between the merchant and the clients of the ISP before payment for the transactions becomes due, and payable by the

ISP.

Once an agreement with an ISP and the merchant is in place, the Agreement reference numbers for the ISP and merchant are recorded in their respective databases. The above process is not initiated again until such time as the merchant or ISP wishes to re-negotiate or end the agreement.

The merchant transmits a merchant reference number for the proposed client purchase together with the product details and the clients Internet address, to a code module on the ISP system Ifa code module on the ISP system can confirm the provided address is authentic, and currently in use, the identity of the client can be determined. The merchant transaction reference number, an ISP transaction reference 1 4 number and the product details are communicated to the Java applet or some other code module on the client system, using the proprietary application protocol over a secure or non-secure link. In the case of a transaction involving the purchase of tangible goods or services requiring physical delivery, a client delivery address is also communicated.

The receiving code module on the client system will display a message box to the client, detailing the merchants Internet address, the products to be purchased, the merchant transaction reference number, the price that will require payment and a request to confirm the details are correct.

If the client accepts the details, the Java applet communicates with a code module on the merchant, and sends the merchant its own (the merchants) reference number, thus confirming to the merchant that the ISP has accepted the transaction. In the case of the purchase of tangible goods or services, the client delivery address is sent.

In the case of the purchase of tangible goods or services, or of electronic services, such as game-play, the ISP transaction reference number is also sent at this time.

In the case of the purchase of electronic goods, the merchant protocol code module downloads the product using a File Transfer Protocol (FTP). On successful completion, the Java applet will send the merchant the ISP transaction 15 reference number.

Once the merchant has acquired the ISP transaction reference number, the transaction is effectively complete.

The ISP protocol code module is sent the ISP transaction reference number using a proprietary application protocol.

The ISP receiving its own transaction number from the merchant confirms that the transaction has been accepted by the client. The ISP and merchant update their respective transaction databases.

A reporting code module on the merchants system will periodically assess the status of transactions it has participated in. If the negotiated Dollar amount of business has been reached between it and an ISP, a code module on the ISP is sent a request for payment. The ISP module will confirm the receipt of the request. A code module on the ISP will search the ISP transaction database and confirm the request. The merchant is then required to be paid as per the agreement, using Electronic Funds Transfer information provided- during the Agreement negotiation, or by some other negotiated means.

All messages transmitted between parties once a request to purchase has been initiated by the client, will use the KIS application layer protocol which describes the particular message types and information format.

The only communication that requires a secure link is that between the merchant and ISP during the Agreement negotiation phase, when information sensitive to either party may be exchanged.

At no time in this invention is the client required to transmit sensitive financial information.

Trust is placed in a single authority, which authenticates the ISP.

The minimal use of secure protocols, and sequence of transaction reference number passing, ensures a system with improved performance and a very high degree of security from the perspective of the client.

The system is implemented as an arbitrary number of software modules on the client, merchant and ISP systems.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING FIG I: This displays a client(l) browsing to a merchant and downloading an HTML page using an HTTP connection A Java applet is downloaded to the client and executes.

FIG 2: The client selects products to buy. The Java applet on the client transmits the product data to the Merchant protocol code module using a KIS protocol connection The protocol code module connects with a transaction code module and a database is searched to check for an agreement record for the ISP (not shown) Ifa record is not found, the protocol code module connects to a protocol code module on the KIS Authority server using a secure or non-secure connection The protocol code module connects to a transaction code 15 module (10) that searches for a record relating to the ISP.

FIG 3: Shows a merchant server negotiating an Agreement with an ISP A secure SSL connection is used between the merchant protocol code module and the ISP protocol code module The results of the agreement are saved 20 in Agreement databases on the two servers, using transaction code modules and .e FIG 4: Shows a Merchant server connecting to an ISP and passing a Validation Request message over non-secure link using the KIS protocol.

The ISP protocol code module connects to the ISP transaction code module which authenticates the client The ISP connects to the client using non-secure link (10) and the KIS protocol.

S- The Java applet on client connects to the Merchant server using a non-secure link (11) and the KIS protocol.

If an electronic product requires delivery, the Merchant server protocol module downloads the product to the client using a non-secure connection (12) with the FTP protocol.

ABSTRACT:

DETAILED DESCRIPTION OF THE INVENTION A preferred embodiment of a system in accordance with the invention includes the following elements The client system from which the customer will initiate a Buy Request from a merchant system, will typically consist of a personal computer of any make or manufacture capable of connecting to the Internet via an Internet Service Provider. The system is required to be able to support the use of an HTML capable Internet Browser package that is at least Java I. I compliant, and preferably, be Java 2 compliant. Java 2 compliance may be achieved by the use of a "Plugin". This is a code module that can be downloaded to the client, and extends the capabilities of a browser it is installed into.

A key element in the preferred implementation of this invention is the use of the Java language. Developed from its inception to be a Networking and Cross-Platform language, Java is ideally suited to the homogenous nature of the Internet. Being described as "The language of the Internet", it comes with support for a wide variety of communications protocols. Being Cross-Platform, Java will work "out-of-the box" on most operating systems, including MAC OS, Microsoft Windows and numerous flavours of UNIX.

Java supports programming with platform-independent Applets. These are small executable programs that may be referenced on HTML documents. When a client browses the page, the Java applet is downloaded to the client system, and executes within the Java aware environment of the Internet browser.

Java was built with the Internet in mind, and security has been a major design consideration since its inception. Java version 1.0 tightly controls the ability of applets to interact with the system and files on the client computer, and to connect to other systems on the Intemrnet. The applet can only connect to the system it was 15 downloaded from, and cannot interact with the filesystem of the resident system.

Version 1.1 allows more flexibility in how the developer can implement the security features of Java applets. Applets can be designated as "trusted", and allowed access to the filesystem and advanced networking.

S Java 2 allows fine grained control of security, so that applets can be trusted to perform very specifically defined operations without compromising the overall security of a clients system.

Java is an Object-orientated language. This means that segments of programming code can be encapsulated as an Object a "Black box" that has a set of defined inputs, and defined functions it can perform. The ability to encapsulate code in this way leads to faster development of more robust and bug free software.

Elements of the preferred implementation: In the preferred implementation, the invention will consist of a number of code modules built using Java.

A Java applet resident on the merchant server will be downloaded to the client. It will be responsible for communicating to the merchant using an application protocol. It will accept communications from the ISP of the client. It may participate in File Transfer Protocol (FTP) transfers from the merchant, and it will present message boxes to the client, and create a graphical interface for the selection of products from the HTML page it is attached to.

One of ordinary skill in the art will appreciate that the construction of such an applet is trivial.

An arbitrary number of code modules may be resident on the servers associated with the invention.

A multithreaded Protocol Module will be responsible for communication between the server and other systems. It will listen in on a TCP/IP port dedicated to use with this invention. It will respond to, and initiate messages from Clients and servers, spawning a new thread to respond to each connection. It will use FTP, Simple Mail Transfer Protocol SSL 3.00 and a proprietary application protocol (to be described) as required. It will communicate with other modules in the KIS application.

Java 2 provides a number of classes for implementing custom protocols. One way is using Protocol Handlers (Stream Handlers) to retrieve web objects using application-specific protocols that are specified in the URL referencing the object. These handlers are implemented as subclasses of the URLStreamHandler class.

The parseURL() and setURL) methods are used to create custom URL syntax parsers.

The java.net package provides classes that support socket-based client/server communication.

The JavaMail API supports the development of client Email modules using SMTP, for the automatic generation of Emails, as optionally available in parts of this invention.

Java extensions, such as the SSLPlus package from Consensus Development Corp. are available to facilitate the coding of the SSL connectivity. The JavaServer Toolkit allows for the easy creation of Java based server modules, providing the capabilities required.

A person skilled in the art will appreciate that the creation of such a Protocol module using Java is an ordinary task using functionality native to the language.

A multithreaded Transaction module will connect to various database tables as required using JDBC drivers, in the preferred implementation. It, or another module will format and parse messages using a predefined syntax..

The java.sql package comes as part of the Java API. JDBC 2.0 is the JDBC API that comes with Java A number of JDBC drivers are available from vendors, for example IDS Software, to connect to various RDBMS.

S 15 Modules specific to particular implementations may be built as required.

•A Reporting module will execute at scheduled times. It will, together with the other modules, evaluate the "status of transactions, and Email and print reports. A person skilled in the art will appreciate that the development of such modules is an ordinary task using Java and its database connectivity functions, and an understanding of 20 Structured Query Language The KIS protocol consists of a number of messages that pass between the client, merchant, ISP and KIS authority.

Each message defines the syntax of the data being transmitted, and may initiate the transmission of other messages.

0oo0 •000 Preferred Implementation: In the preferred implementation of the invention, a clients ISP will offer the services provided by this invention, henceforth described as "KIS", to its clients, depending on the relationships that exist. If the client is acceptable to the ISP and accepts the offer, they are entered into the ISP client database as a KIS user, optionally allocated a Credit Limit, and an application is downloaded to the client. This application when run, will modify the Java security policy on the clients system, allowing Java applets the ability to communicate with the ISP on a specified Internet Protocol (IP) address and port number. If required, a Java 2 plugin is also downloaded and installed.

Alternatively, the Java applet provided by the implementers of this invention may be digitally signed, and if a Java 2 implementation is not achievable, then a public key that can verify the trustworthiness of the applet is downloaded. In any event, the applet is enabled to communicate with the ISP on the designated port.

The Java applet may typically display checkboxes with a description of the products and prices as encoded within the <APPLET> or other tags on the host HTML page, a Totals field and a BUY button. When the customer selects one or more products and clicks the BUY button, the applet formats the data into a transaction message using the predefined syntax of the KIS protocol.

The message will contain at least the following information: HEADER Identifies this as a KIS message MESSAGE TYPE Buy Request message type ISP KIS IP ADDRESS CLIENT IP ADDRESS PRODUCT DESCRIPTION May repeat several times TOTAL PRICE TERMINATOR End of message Indicator The Header, Message Type and Terminator fields will be present in all the KIS message types. The Header will identify This as a KIS protocol message. The Message Type will identify the structure of the particular message.

The ISP IP address provided in the message will be that provided by the ISP during the Client setup process.

The Java applet on the Client will initiate communication with the merchant system Server from which it is downloaded, using Transmission Control Protocol/Internet Protocol described in the Information 10 Sciences Institute, "Internal Protocol DARPA Internet Program Protocol Specification (RFC 791)" (September 1981).

The communication will be to a port number on the server, designated to be the KIS port number on all server systems wishing to be KIS compliant.

Once the TCP/IP link is established, the KIS Buy Request message is transmitted. A simple encoding scheme may be optionally employed to protect the message from casual browsing of the IP packets. The emphasis here is on performance however, and since no sensitive information is being transmitted, this is not a requirement.

At the KIS compliant merchant server, a multithreaded application is executing. In the preferred implementation this is written in Java, however other languages, such as may be used in a particular implementation.

A Protocol module will be listening in for communications on the KIS allocated TCP/IP port number. When the 20 Client message is received, a Header identifies it as a KIS message type.

The message type field indicates the message to be a "Buy Request". The Protocol module passes the message to a Transaction module, which creates a new record in a Transaction database. A Transaction Reference number is generated and added to the new record.

Merchant to KIS Authority: At the same time, another module is checking the ISP IP address against a KIS Agreement database. If a record is found, then a status field will indicate the current status of any agreement previously entered into with the ISP. If no record is found, then the protocol module initiates communication with an authority, henceforth the KIS Authority.

The KIS Authority will maintain a database of all KIS compliant ISP servers. The records will contain amongst other data, the ISP authorized IP address specified for KIS transactions, A public key of a key pair known to be valid for the ISP, and a Status indicator that may be used to indicate the reliability of the ISP as an Agreement partner. This communication may be conducted using TCP/IP and the KIS protocol, or optionally using a secure SSL link. If the secure link option is chosen, the message is encrypted using a public key of a key-pair provided by the KIS authority. The message type is an "Authentication Request". The message will contain at least the following fields: Authentication Request Merchant to KIS authority.

HEADER

KIS header MESSAGE TYPE Authentication Request message ISP KIS IP ADDRESS ISP KIS designated IP address MERCHANT KIS IP ADDRESS Merchant KIS designated IP address TERMINATOR End of message indicator The KIS authority will respond with an "Authentication Result" message containing at least: HEADER KIS header MESSAGE TYPE Authentication Result MERCHANT KIS IP ADDRESS ISP KIS IP ADDRESS STATUS Status indicator for ISP ISP PUBLIC KEY TERMINATOR End of message indicator If the link is an SSL connection, the message is encrypted using the private key of a key-pair.

If the ISP IP address is unknown, the status field indicates this. In this case, the merchant will decline the Buy Request from the client. The client will be presented with a message indicating that the ISP is not KIS compliant.

Merchant to ISP Communications: If the KIS authority authenticates the ISP, or if the Agreement database indicates an existing agreement with the ISP has expired, then the protocol module will initiate communications with the ISP over a secure SSL link. The message will be a "Negotiation Request". It will suggest a number of alternative agreement options in order of the merchants preference. These options will be selected from a KIS Options table supplied and maintained by the KIS authority. The message will contain other data relevant to setting up the agreement, and will contain at least the following values: Negotiation message Merchant to ISP First time Negotiation. (SSL) HEADER Header MESSAGE TYPE Negotiation Request MERCHANT AGREEMENT Merchant agreement reference number VERSION KIS Option table version number OPTION KIS Option table option first choice OPTION 2 nd choice OPTION 3 r d choice EMAIL Merchant Contact details MERCHANT KIS IP ADDRESS IP address used for KIS communications The KIS Options Table will define a number of Payments and Fee options on which to base an agreement.

The values in the table will be set by agreement amongst all participating KIS server users. From time to time, the values may be changed. At least two types of options will be available to choose from: 1) A TRIGGER/FEE method 2) A VALUE/FEE method.

The TRIGGER/FEE method will define a number of Trigger dollar values and an associated fee. The Trigger value is a dollar value of transactions that occur between the merchant, and the clients of the ISP, before payment becomes due. The Fee is a percentage of the Trigger value that the ISP will charge for facilitating the transactions. An option will be available for a Lead Time to be imposed, before a Trigger becomes active. For example a lead time of 30 days may be imposed, in which case only transactions older than 30 days may accrue towards a Trigger value. When the o15 trigger dollar value is reached, the merchant is due payment. For example: Option 2: Trigger $2000.00, fee 1% Option 3: Trigger $2000.00, fee Option 3: Trigger $200.00, fee 2% S Option 4: Trigger $500.00, fee Option 5: Trigger $100.00, fee 0 S"The VALUE/FEE method will define a number of options where a Fee is charged, depending on the Value of each transaction. Typically a smaller valued transaction may incur a higher percentage fee than a transaction of greater dollar value. In this scheme a range of fees relating to different valued transactions will apply in any given option.

"•OWith this method, the payment trigger would be a time interval, such as 30 days.

For example: Option Value less than $2.00, fee 3% Value less than $5.00, fee 2% Value less than $10.00, fee 1% Value greater than $10.00, fee The current KIS Options table will be distributed to the KIS compliant servers at the software installation time.

Updated tables may be distributed by the KIS authority, or manually updated using a utility program. The Negotiation Request message may contain a version number for the KIS Agreement table used.

The communication from the merchant to ISP is encrypted using the ISP public key provided by the KIS authority. The KIS authority is trusted to provide the public key of a key pair belonging to the ISP. If the ISP can successfully respond to the encrypted Negotiation Request message, then the merchant is assured of the identity of the

ISP.

The ISP protocol module will decrypt the Negotiation Request message using its private key in the key-pair.

The merchants identity as described by the data provided may be checked against a status field in an Agreement database, to ensure the merchant is suitable to do business with.

An ISP module will iterate through the merchant options in the Negotiation Request message until a suitable match with its requirements is made. An Agreement reference number is generated and a Negotiation Response message formatted. If the ISP does not wish to make an agreement, the ISP Agreement reference number is Null. The merchant may initiate other Negotiation Request messages, with other options. The Negotiation Response message will contain at least: Negotiation Response ISP to Merchant (SSL)

U..

S. 1

S

S..

S

S

HEADER Header MESSAGE TYPE Negotiation Response ISP AGREEMENT REFERENCE NUMBER ISP Agreement reference or NULL if no agreement MERCHANT AGREEMENT REFERENCE Merchant number.

OPTION Selected option or NULL if no suitable option EMAIL Contact details DATE Date stamp TERMINATOR Message terminator The ISP protocol module creates a digital signature consisting of a digest of the message and a sequence number. The signature and message are encrypted using the private key of the key-pair and transmitted to the merchant using the SSL protocol. The protocol module at the merchant server decrypts the message and the signature, and compares the digest with one it computes itself. If the digests match and the sequence number is valid, the merchant is assured that a bone fide agreement has been reached. A transaction module updates the KIS Agreement database with the agreement details.

When an agreement is in place with the ISP, the Clients Buy Request can proceed. This may be after the Negotiation phase described above, or immediately after it has been verified an agreement already exists. This message phase is not encrypted, using TCP/IP and the KIS protocol only. A validation Request message is formatted and transmitted by the merchant protocol module. It contains at least: Validation Request- Merchant to ISP HEADER Header MESSAGE TYPE Validation Request MERCHANT TRANSACTION REFERENCE Merchant Transaction reference MERCHANT AGREEMENT REFERENCE Merchant agreement reference MERCHANT INTERNET ADDRESS (URL) PRODUCT(S) Product description -II

S.

S

A module on the ISP server will verify with modules not part of the KIS invention, that the client IP address is valid for the ISP and currently in use. The specific user is identified for billing purposes. The transaction details in the message are used to build a new transaction record in a Transaction database. A non-sequential ISP transaction reference number is generated, and added to the record. If the Delivery flag indicates actual delivery is required, then a Delivery address sourced during the client setup process, is acquired from a customer database.

ISP to Client Communications: A Client Accept message is formatted. It contains at least: Client Accept ISP to Customer HEADER Header MESSAGE TYPE Client Accept MERCHANT TRANSACTION REFERENCE Merchant transaction reference MERCHANT INTERNET ADDRESS (URL) ISP TRANSACTION REFERENCE ISP transaction reference PRODUCT(S) Description PRICE Price EMAIL Customer Email address (option) DELIVERY ADDRESS Delivery address (option) TERMINATOR Terminator The ISP protocol module transmits the Client Accept message to the Java Applet on the clients system, using TCP/IP and the KIS protocol only.

The Java applet on the client system builds and displays a message box containing at least: 0 00 S. 0 0 MERCHANT INTERNET ADDRESS (URL) MERCHANT TRANSACTION REFERENCE

PRODUCT(S)

PRICE

The text on the message box will request the client to verify the details shown, and accept or reject the transaction by clicking an OK button or a CANCEL button.

-12- Client to Merchant Communication: If the client accepts the transaction, then the applet will communicate with the protocol module on the merchant server. The Client Accept message is formatted. The contents will depend on the type of goods or services being purchased in this transaction. The message could contain: Client Accept Customer to Merchant HEADER Header MESSAGE TYPE Client Accept MERCHANT TRANSACTION REFERENCE Merchant Transaction reference ISP TRANSACTION REFERENCE ISP transaction reference. See note (1) PRODUCT(S) Descriptions PRICE Total price CLIENT IP ADDRESS Customer IP address CLIENT EMAIL ADDRESS DELIVERY ADDRESS Delivery address (option) See note (1) TERMINATOR Terminator 1. If the goods or services will require physical delivery, then the delivery address, Email address and the ISP reference number are included in the message. This concludes the KIS interaction between the client and the merchant.

2. If a service is purchased that requires No delivery, physical or electronic, then the ISP reference number is included in the message. The Email address does not need to be provided. This concludes the KIS interaction between the client and the merchant.

3. If the goods will require delivery via the File Transfer protocol (FTP), the Email address is sent. The ISP reference is Not included in the message at this time. The protocol module on the merchant server will now initiate a download of the goods using FTP, over TCP/IP. On completion of the download, the Java applet on the client will send a "Buy Completion" message type, using TCP/IP and the KIS protocol. This will typically include: Buy Completion HEADER Header MESSAGE TYPE "Buy Completion" MERCHANT REFERENCE NUMBER Merchant Reference number ISP REFERENCE NUMBER ISP reference number EMAIL Customer Email address TERMINATOR Terminator On receipt of the Buy Completion message, the transaction is complete from the perspective of the client.

The possession of the ISP transaction reference number by the merchant indicates the transaction completion. Finally, -13- 14 using TCP/IP and the KIS protocol, the protocol module on the merchant sends a "Transaction Completion" message to the ISP. This includes at least: Transaction Completion Merchant to ISP HEADER Header MESSAGE TYPE "Transaction Completion" MERCHANT TRANSACTION REFERENCE NUMBER Merchant Reference number ISP TRANSACTION REFERENCE NUMBER ISP reference number MERCHANT KIS IP ADDRESS TERMINATOR Terminator 10 On receipt of the Transaction Completion message, a module on the ISP will check the provided transaction numbers against those in the incomplete transaction record. If the reference numbers match, then a Transaction completion status message is sent: Transaction Completion Status ISP to merchant.

HEADER Header MESSAGE TYPE "Transaction Completion Status" MERCHANT TRANSACTION REFERENCE NUMBER Merchant Reference number ISP TRANSACTION REFERENCE NUMBER ISP reference number

STATUS

ISP KIS IP ADDRESS TERMINATOR Terminator If an error has occurred, such as No match between reference numbers, the status field will indicate this.

Otherwise both the ISP and merchant now complete their transaction records, and the transaction is complete.

If an error has occurred, then the record is flagged with an error status. Optionally an email is automatically sent to a nominated supervisor for their attention.

Reporting Module: Each KIS compliant server will have a Reporting module, a Java application in the preferred implementation.

At regular intervals set by the user, the module will check on the status of the Transaction database. Transaction records that were not completed within a configured time period will be purged.

On the merchant server, the transactions that have been triggered ie that qualify for inclusion in a Trigger dollar amount, or fall within a given time frame are totalled. If a trigger condition has been met, then a "Pay Request" message is sent to the respective ISP. The message contains at least: -14- Pay Request Merchant to ISP sent when it calculates the trigger has been reached.

HEADER Header MESSAGE TYPE "Pay Request" ISP AGREEMENT REFERENCE ISP agreement reference number MERCHANT AGREEMENT REFERENCE Merchant agreement reference number MERCHANT IP ADDRESS END DATE Transactions older than this date DATE Current date TERMINATOR Terminator On receipt of the Pay Request message, the protocol module acknowledges receipt of delivery. The Payment request is stored in a database until processed.

Pay Acknowledgment- ISP to Merchant acknowledgment of receipt of Pay Request.

HEADER Header MESSAGE TPE "Pay Acknowledgment" ISP AGREEMENT REFERENCE ISP agreement reference number MERCHANT AGREEMENT REFERENCE Merchant agreement reference number DATE Current date TERMINATOR Terminator If the merchant does not receive the Pay acknowledgment reply after a number of retries, an Email is automatically generated and sent to the ISP contact address, and the merchant administrator.

At the ISP, the reporting module is run at scheduled times. When executed, it checks for Pay Request messages. The transaction database is checked, and all transactions that qualify are totalled. The merchant is paid less fees and less any disputed transactions. An Email is sent detailing the dispute. Reports are generated. Payment processing is outside the scope of this invention.

Features of the Invention: 1) The only communication that Requires a secure connection, is that between the merchant and ISP when they first negotiate an agreement. This is to assure the merchant that a genuine agreement has been made, validated by the digital signature provided by the ISP. The SSL 3.0 connection will use public and private key encryption. The public key of a key-pair owned by the ISP is used by the merchant for encryption/decryption purposes. The merchant is not authenticated by the ISP. SSL 3.00 will be used to allow negotiation of the Cipher suite.

The merchant receives both its and the ISP transaction reference number from the client. This proves that the messages have been routed via the ISP to the client. If the public key for the ISP as provided by the KIS authority can be trusted, it follows that the ISP can be trusted. Since it receives back its own reference number via the 16 trusted ISP, it can trust that the ISP reference number is also genuine. le, the client has indeed been accepted as suitable to participate in the transaction. A chain of trust has been created.

2) The merchant will only receive the ISP transaction reference number from the Client. The Client will only possess the reference number if the ISP has authenticated it. Therefore the merchant can prove that the client was authenticated by the ISP. In the case of the purchase of electronic goods, the Merchant will only receive the number when it has downloaded the product. Therefore it can also prove to the ISP that the goods were delivered.

Delivery of an on-line service or manual delivery, cannot be proved.

3) The ISP is Responsible for the payment of all transactions that "mature" in a given time period, irrespective of whether the Client has made payment to them, provided the transaction is not "In Dispute". With this responsibility comes the opportunity to become a "Credit facility" for the client base, and gaining another income stream.

o

oo:O 1) A method for enabling financial transactions over the Internet, comprising the steps of: a) Parsing data on a client computer system and generating a formatted Purchase transaction in accordance with a predefined syntax; b) Establishing a communications link between the client and a merchant server; c) Transmitting the Purchase transaction across the link from the client to the merchant server; d) Checking a transaction database to determine the presence or status of any existing agreement between the omerchant and the ISP; S°e) Communicating with a Trusted authority to authenticate the ISP; f) Establishing a secure communications link between the merchant server and the ISP; 25 g) Generating an encrypted message formatted according to a syntax, containing a "Request.todo business"; S°h) Communications between the merchant and ISP of messages formatted according to a syntax, establishing the parameters of an agreement, over the secure link.

i) Reformatting and transmitting the Purchase transaction from the merchant to the ISP; j) The ISP verifying the status of and authenticating the client; k) The ISP communicating the reformatted Purchase transaction to the client; I) The Client communicating an acceptance of the Purchase transaction to the merchant; m) The acceptance and conclusion of the transaction by the merchant; n) The merchant communicating to the ISP the completion of the Purchase transaction.

2) A system for enabling financial transactions over the Internet, comprising of: a) Means for parsing data on a client computer system and generating a formatted Purchase transaction in accordance with a predefined syntax; b) Means for establishing a communications link between the client and a merchant server; c) Means for transmitting the Purchase transaction across the link from the client to the merchant server; d) Means for checking a transaction database to determine the presence or status of any existing agreement between the merchant and the ISP; -16-