WO2000065493A2

WO2000065493A2 - Delegation billing

Info

Publication number: WO2000065493A2
Application number: PCT/CA2000/000419
Authority: WO
Inventors: Chun-Yen Cheng; Stanley T. Chow; Harold J. Johnson; Yuan Gu
Original assignee: Cloakware Corporation
Priority date: 1999-04-22
Filing date: 2000-04-20
Publication date: 2000-11-02
Also published as: AU3952400A; WO2000065493A8; CA2371115A1

Abstract

The present invention relates generally to electronic commerce, and more specifically, to a method and system of executing electronic commerce transactions over the Internet. Existing electronic commerce solutions have scalability and security problems which have prevented their widespread use. The invention provides a flexible solution that does not have the same demands on bandwidth, memory and processor power, and at the same time is very secure. An access certificate is created which describes a billing chain between a Service Provider and an End User, generally passing through the End User's Internet Access Provider with whom he has an invoicing arrangement. This billing chain gives the Service Provider assurance that he will receive payment for the service being supplied, and allows the Service Provider to defer invoicing and collecting tasks to the Access Provider.

Description

Delegation Billing The present invention relates generally to electronic commerce, and more specifically, to a method and system of executing electronic commerce transactions over the Internet.

Background of the Invention

It is well known that data communication networks such as the Internet, Wide Area Networks (WANs) and Local Area Networks (LANs), offer tremendously efficient means of organizing and distributing computerized data. These efficiencies have resulted in their widespread use in both public and private life, for business and personal use. The prospect of using these networks as an inexpensive channel of commerce has become very appealing. In particular, due to the penetration of the Internet into the residential market, personal sales over the Internet network presents a potentially major market for electronic commerce. However, the existing methods and systems of supplying such electronic commerce services have numerous shortcomings which have prevented their general acceptance and use.

The Internet consists of a vast interconnection of computers and computer networks which allows two parties to communicate via whatever entities happen to be interconnected at any particular time. Presently, connecting directly to the Internet is beyond the financial means of most End Users and thus new businesses known as

Internet Access Providers have proliferated. These Access Providers invest in the equipment needed to provide access to the Internet for End Users who pay a fee for the Internet access. Typically, an End User may communicate with an Access Provider using a modem to communicate over a telephone network to the Access Provider's equipment, which in turn connects the End User to the Internet.

Service Providers are entities who advertise their products and services on web sites accessible over the Internet, and receive orders from Internet End Users for these products and services. Currently, the most common method of payment is by credit card, but there is a reluctance among End Users to transmit credit card account information over the Internet because of its lack of security.

Even if somewhat reliable encryption techniques are used to encode the private credit card data, there are still security risks to making such transmissions. For example, an End User who accesses the same Service Provider sites on a regular basis, or accesses a large number of sites, may end up transmitting his private credit card data a tremendous number of times. This high level of exposure will leave the End User open to theft, even with security measures in place. It is possible, for example, to intercept Internet packets destined to or originating from a specific End User or web site. If an End User transmits his credit card data using a variety of different coding techniques, the interceptor may be able to identify a pattern which allows him to decode the encrypted credit card data.

As well,^' the End User's private credit card data must be decoded by the Service Provider, which leaves the decoded credit card data vulnerable to attack either from the Internet or from within the Service Provider's facilities. Again, the more sites that the End User accesses and transmits credit card data to, the greater the exposure to such an attack.

Service Providers are also reluctant to participate in such transactions as they must establish accounts, verify the credibility of each End User, record transactions, invoice, and collect payment of accounts. This is a substantial overhead and may be a barrier to entry into the Internet market for smaller Service Providers. Larger Service Providers may not be interested in taking on such activities that are not otherwise part of their core business.

Credit and debit card numbers can be verified electronically at secure credit servers to minimize losses due to the use of lost or stolen cards, or to identify card holders who exceed their credit levels, but this requires that every transaction be verified on line and in real time. This verification is an additional overhead in terms of bandwidth and time to execute, and does not always provide reliable data. Among other things, the reliability of this verification depends on how frequently the credit server is updated. With a large number of Service Providers continuously requesting credit information and providing billing updates, there is a scalability problem, particularly with transactions in the order of a few cents each. If the credit data is not updated on line and in real time, or the Service Providers do not request authorization for small transactions, then the available credit data is unreliable and there is potential for errors, tampering or abuse.

Another aspect of present electronic commerce is the difficulty of providing a very large number of services with very small monetary values. Because it is not economically feasible for Service Providers to bill and collect electronic transactions where the value is in the order of a few dollars, pennies or fractions of pennies, such low value services are either not made available by Service Providers, or are provided at no cost. A scalable system which is able to handle a large number of small-sized transactions in an efficient manner would offer greater compensation to Service Providers and encourage provision of low value services heretofore unoffered.

Therefore, there is a need for improved security and scalability in executing commercial transactions over the Internet. There are many schemes for electronic commerce currently available which have attempted to address these issues, but all have major shortcomings which have inhibited the growth of the Internet electronic commerce market.

Several such systems use central servers as Brokers to convert real money into encrypted electronic money which may be used to obtain services. These systems require the Service Provider to store and forward each electronic coin to the Broker for reimbursement, requiring large memory overheads at the Service Provider. Some of these systems encrypt these electronic coins in such a manner that the Service Provider can validate them, but this validation is at the expense of additional overheads of processing power and memory to verify and store each encrypted coin. Other systems require that the Service Provider refer the coin to the Broker for verification, with corresponding overhead costs of time, and transmission and reception bandwidth to the Service Provider.

The creation and verification of these electronic coins depends on the accessibility and reliability of these Brokers. For example, if the Broker Servers are inaccessible for some reason, the system can not operate at all. As well, it is not clear what Users are to do with small or fractional balances of electronic currency. More importantly, both the Service Providers and End Users rely on the Brokers to secure the value of the electronic coins, as the electronic coins otherwise have no market value. If the Broker becomes insolvent, the electronic coins may become worthless.

Another system uses smart cards, which are more sophisticated than credit or debit cards as they employ microprocessors and solid state memory to store electronic coins or credit data, rather than simple magnetic strips. These systems require additional hardware, in the form of an electronic interface, to access the contents of the smart card. Clearly, such systems do not offer the flexibility and mobility of software based systems which may be implemented on laptop computers, personal digital assistants or Internet-ready cellular telephones. Another solution is proposed under United States Patent No. 5,794,221 which requires the Access Provider to be an intermediary between the Service Provider and the End User. This method has numerous shortcomings as well. For example, this system requires that the Access Provider deal directly with both ends of each transaction, making the number of "commercial relationships" huge, as it is necessary to have a specific relationship for each pairing of End Users and Service Providers.

As well, because the Access Provider participates in every transaction between each pairing of End Users and Service Providers, a great demand is placed on the available processor-cycles and bandwidth of the Access Provider's infrastructure. This also decreases the reliability of the system, as more network entities and intercommunications are involved. This is not a scalable solution to the electronic commerce problem.

None of the above systems offer non-repudiation as an inherent feature, though it may be added on at the cost of additional bandwidth and processing overhead. Non-repudiation is useful as it means that an entity can demonstrate that another entity had agreed to a certain transaction, made a certain request or accessed a certain web site. That is, an entity can not repudiate the fact that it did a certain thing. In general, non-repudiation may be added to the above systems by combining them with known cryptographic signature techniques, but such a solution places even greater overhead and operational demands on the system than those described above.

Most of the above methods require some form of cryptographic signature or public key infrastructure to operate at all. The key-management that these techniques introduce has scalability problems which are very difficult to overcome, particularly if key-revocation is required. Increased cost, decreased speed, bandwidth and reliability, as well as numerous key-management problems result. It is necessary to create a system which reduces the above obstacles in order to encourage the widespread commercial use of electronic commerce over the Internet. It is further desirable that such a system be flexible so that entities may perform what activities in the electronic transaction they wish, allowing them to refer billing, accounting and collecting processes to other entities, rather than handling these functions themselves. It is also desirable that such a system be scalable, in that it can handle capacity increases in a manageable way rather than requiring linear increases in system resources.

There is therefore a need for a method and system of executing electronic commerce transactions over the Internet, which provides for an improvement over the problems outlined above.

Summary of the Invention

It is therefore an object of the invention to provide an improved method and system of executing electronic commerce transactions over the Internet. One aspect of the invention is broadly defined as a method of executing an electronic commerce transaction between a first entity and a second entity via one or more intermediate entities over a communication network, the method comprising the steps of: generating an access certificate describing a billing chain and including the identification of each entity in the billing chain; at the first entity, transmitting the access certificate to the second entity; and at the second entity, accepting the access certificate as assurance of payment and providing a service to the first entity.

Brief Description of the Drawings

These and other features of the invention will become more apparent from the following description in which reference is made to the appended drawings in ^• which: Figure 1 presents a flow chart of a method for electronic commerce in a broad embodiment of the invention; Figure 2 presents a schematic diagram of the process for electronic commerce in a broad embodiment of the invention;

Figure 3 presents a flow chart of a software routine to authenticate a First Computer

Program to a Second Computer Program in a manner of the invention; Figure 4 presents a physical layout of a communication system in a preferred embodiment of the invention; Figure 5 presents a schematic diagram of a process for establishing an access certificate in a preferred embodiment of the invention; Figure 6 presents a flow chart of a method for executing an electronic commerce transaction in a preferred embodiment of the invention; and Figure 7 presents a schematic diagram of a method for obtaining payment of an electronic commerce transaction in a preferred embodiment of the invention.

Detailed Description of Preferred Embodiments of the Invention A method which addresses the objects outlined above, is presented broadly, as a flow chart in Figure 1. This flow chart presents a method of executing an electronic commerce transaction between a first entity and a second entity via one or more intermediate entities over a communication network. The electronic commerce transaction begins at step 10 by generating an access certificate which describes a billing chain. A billing chain is the path that the billing information takes in travelling from the entity providing the service, in this case the second entity, to the party receiving the service, in this case the first entity. This path may pass through several intermediate entities in the communication network which have a presence on the communication network, and have an interest in the transaction. The participation of these intermediate entities will be described in greater detail hereinafter.

The access certificate is an electronic packet which contains a record of the identification of each entity in the billing chain. If the invention is applied to an Internet network, these identifications may comprise Universal Resource Locator, or URL addresses. However, it is preferred that a more condensed identifier be assigned by the only entity which uses this identification. That is, the prior entity in the billing chain. This allows the size of the packet to be minimized and also allows entities to be anonymous except to the prior entity, as any arbitrary identifier may be used.

Once the access certificate has been created, the first entity may use it to request a service or product from the second entity, shown as step 12 in Figure 1. Because the access certificate has been accepted by the entities necessary to establish payment for the service, the second entity accepts the access certificate as assurance of payment at step 14 and provides the requested service to the first entity. This method may take on the physical realization presented in Figure 2. The step of generating an access certificate 10 is realized by passing the access certificate to each entity in the billing chain, so that all of their identities may be added to the access certificate. This process may be initiated by the second entity 16 in response to a request from the first entity 18 at step 12, but is preferably done ahead of time. This is due to the fact that the second entity 16 and intermediate entities 22 and 24, will generally require formal licenses to be negotiated and executed between the adjacent pairings. This process will be described in greater detail with respect to Figures 5 and 6. As note above, the access certificate may be a data packet containing identification of the entities in the billing chain. It also may include restrictions to the value of credit being requested, length of time it is valid and other parameters.

The intermediate entity 22 adjacent to the second entity 16 may be identified by the second entity 16 based on some technical or business model, or may be selected from a table of available intermediaries which offer the necessary functionality. This intermediary 22 finds a routing back to the first entity 18 via other intermediate entities 24 using a similar selection process. The line between intermediary 22 and intermediate entity 24 is presented as a hatched line to indicate that additional intermediaries may also be involved in the transaction. In that case, the identification of those additional intermediaries would also be included in the access certificate.

As will be described with respect to the preferred embodiment, it is preferred that the intermediate entity 24 adjacent to the first entity 18 have a pre-arranged billing relationship with the first entity 18. In the context of an Internet application, the intermediary 24 may be the Access Provider for the First Entity 18, the First

Entity 18 being an End User with a pre-arranged account with the Access Provider. In the context of a large corporation, intermediary 24 may be the Internet server of the corporation, which would take responsibility for the transactions of its employees, represented by first entity 18. Each entity indicates its acceptance of the access certificate by appending the identification of the next entity to the access certificate and forwarding the access certificate to the next entity in the billing chain. If the access certificate is not acceptable, an entity may choose not to forward it. It is also preferred that in such an event, the entity rejecting the access certificate return an indication of the rejection to the prior entity that sent it the access certificate. This rejection could also include an explanation, so that the End User or other entity may take remedial action to execute the desired transaction.

Once the access certificate has been generated, the first entity 18 may forward the access certificate to the second entity 16 along with the request for a service, at step 12. Since the second entity 16 now has the assurance of payment via the routing in the access certificate, it provides the requested service to the first entity 18 at step 14. This may take an electronic form, such as transmitting a newspaper article, stock quotation or a new piece of software to the First Entity 18 over the Internet, or a physical form, as in shipping a pair of shoes to the First Entity 18 by post or courier.

Implementation of the invention with different forms and levels of security will be discussed hereinafter, but the logistical advantages of the invention are clear, regardless of the security measures employed. For example, the entity providing the service to the End User no longer has to handle all of the billing, accounting, credit rating of End Users and collecting payment of accounts. These functions may now be performed by other entities in the billing chain.

Once generated, the access certificate may be used repeatedly between the first entity 20 and second entity 16, so that communication through the entire billing chain for each transaction is no longer necessary. This is in contrast to several known systems which require each transaction to pass through several entities. This access certificate may include a time limit, maximum approved credit, maximum number of transactions or similar limitations, reducing the exposure of the transaction and its contents to attack.

The invention is also flexible in that different entities in the billing chain may perform different functions. For example, in the preferred embodiment, a model of the invention will be described which parallels the existing model of manufacturer - distributor - retailer - customer. This model will allow Service Providers to implement a web based system that corresponds with existing sales practices between Distributors and Retailers.

This flexibility also allows the memory and processing resources of different entities to be optimized. For example, a Service Provider may wish to act as its own distributor, cutting out a middleman that might otherwise share in the profits. This would be at the expense of the additional overheads to handle the functions being assumed by the entity. Conversely, an entity that already has the infrastructure to handle billing, accounting and collecting, or wishes to assume this role, may become a specialist who performs these services for several other Service Providers. The intermediate entities 22 and 24 in the invention do not deal directly with both ends of each transaction, as some known systems require, so the method of the invention executes faster than the known methods. As well, the intermediaries 22 and 24 only need one record per each adjacent entity, while the known systems often require one record for each pairing. This results in lower overhead at the intermediate entities 22 and 24 as well.

The invention has increased reliability over other systems, as fewer entities and intercommunications are involved for each transaction, increasing the likelihood of a successful transaction. The Internet for example, does not guarantee successful communication, and "timing out" is often employed as a security measure. The greater the number of entities that must participate in a transaction, and the greater the amount of processing they must perform, the lesser the likelihood of a successful transaction within the timeout windows.

In the context of the Internet, the first entity 20 may be an End User, the second entity 16 a Service Provider with a web site on the Internet, and the intermediate entity 24 adjacent to the End User, an Access Provider. Because the Access Provider already has an account arrangement with the End User, their acceptance of the access certificate gives the assurance of payment to others in the billing chain. Therefore, the End User does not have to transmit credit card account information over the Internet. As well, the End User's private credit card information need not be de-coded and stored on the Service Provider's Server as in the case of some known systems, which leaves it vulnerable to attack either from the Internet or from within the Service Provider's facilities. Furthermore, there is no increase in exposure to attack to the End User regardless of how many web sites are accessed and how often.

There is no need to verify credit and debit card numbers, so there is no overhead of time or cost to verify, no requirement for on line or real time verification, and no time lag to update credit databases.

Further advantages can be obtained by implementing the access certificate with delegation of authorization. One or more of the entities in the billing chain is empowered to determine what rights are to be offered to the End User, subject to the acceptance of the other entities. By delegation, it is meant that the empowered entity passes authorization to the End User to exercise those rights. For example, an intermediate entity which has authorization to access a certain service on the Service Provider's web site may transmit a corresponding password to the End User that allows the End User to have this access.

This concept of delegation allows the invention to realize a number of additional benefits. For example, it allows Service Providers to delegate the functions of billing and collecting. This makes the provision of a large number of small transactions economically feasible. Service Providers only need to record a running balance of each End User's account, rather than storing each transaction or even each individual electronic coin as required by some existing methods.

This allows Service Providers to offer services having costs in the order of a few dollars, pennies or even fractions of pennies, encouraging more such services to be provided as Service Providers can now be compensated without onerous overheads. A large number of small-sized transactions over the Internet would offer greater compensation to Service Providers and encourage provision of services heretofore unoffered. Because the intermediaries 22 and 24 only need to participate in the set up and billing processes, and not in accounting for every transaction between each pairing of End Users and Service Providers, much smaller demand is placed on the available processor-cycles and bandwidth of the intermediaries' 22 and 24 infrastructures. As well, with the invention, there is no need to use encrypted electronic currency with its inherent risks and inefficiencies.

As the access certificates are established with predetermined conditions, including currency limits, by means of the delegation, far fewer credit queries are required, ameliorating the real time demands on the Access Provider. The improvement in efficiency is particularly notable in the application of the invention to large numbers of small transactions. In the prior systems, if a Service Provider waited to reach a threshold before referring to the credit service, then there was a chance that credit would not be given and the Service Provider would lose the money. However, if the Service Provider referred to the credit server for every 0.02$ transaction, the time required to make all of the necessary verifications would be immense and the corresponding bandwidth loss would be unbearable. The invention allows the best of both worlds. For example, if the access certificate pre-approves the End User for $1.00, then 50 x 0.02$ transactions could be executed before requiring a new access certificate. This reduces the time and processing demand by a factor of 50 without any increased risk in payment or confusion regarding the balance of the End User's account. The system is scalable in this respect, and minimizes the potential for tampering or abuse.

By using arbitrary identifications or customer names assigned by the prior entities rather than actual names or URL addresses, a reasonable degree of anonymity and privacy is offered. Each party in the transaction knows only the next and previous party in the billing chain, but no further.

This access delegation may be advantageously applied with the use of a non- reversible authentication process such as that described in United States Patent Application, Serial No. 09/134,731. This method is presented in Figure 3, with respect to a First Computer Program which authenticates to a Second Computer Program. These programs may be employed by different entities as will be described hereinafter.

The method of non-reversible authentication generally consists of generating a hash sequence by executing a non-reversible function on a seed value as shown at step 28. Note that both the First Computer Program and the Second Computer Program are operable to execute a like non-reversible or hash function and that the particulars of this function and how it operates need not be secure. This function may be based on one known in the art, such as MD5 from RSA or the SHA algorithm from NIST. The invention relies on the non-reversible property of such functions; that given the function and a product of the function, it is very difficult to calculate the operand.

For example, using a simple non-reversible function such as the additive congruential pseudo-random number generator known in the art: x_i+1 = (9731 x, + 12357) mod 997 where "mod" is the modulus function which yields the remainder when (9731 x,+ 12357) is divided by 997, and 9731 , 12357 and 997 are arbitrary constants, given a seed value of X_Q = 5, a series may be generated as follows: x. = 9731 * 5 + 12357 mod 997 = 61012 mod 997 = 195 x₂ = 9731 * 195 + 12357 mod 997 = 1909902 mod 997 = 647 x₃ = 9731 * 647 + 12357 mod 997 = 6308314 mod 997 = 295.

Even knowing a value of X_| and the constants 9731 , 12357 and 997, it is very difficult to determine the value of x_M. For this example, testing each possible equation to find the value of x one would have to calculate as many as 997 equations.

If the constants and x, were in the order of 128 bits long, then as many as 2¹²⁸ equations would have to be calculated. Even with a computer executing 1 billion calculations per second, it would take 10²² years to test all the possible equations.

This simple function is given for the purpose of illustration only. As it is linear, it is straightforward to solve for the operand, making it unsuitable for cryptographic use. However, there are more sophisticated non-reversible functions known in the art for which no practical way of performing reverse calculations has yet to be devised. The MD5 and SHA algorithms are well known examples of such functions. The First Computer Program uses this non-reversible function to create a series of passwords from S₀ to S_n, by successively executing the function on a seed value S„. As noted in step 28 of Figure 3, each S, is calculated by executing the non-reversible function on the previous password S_M. It is a property of the non- reversible function that there is no practical means for calculating S_M from knowledge of the non-reversible function and the last password S,. Therefore, successively previous values of S can be used as passwords because they can not be generated from knowledge of old passwords.

Of course, it is quite easy to verify that a new password is in the same sequence as the previous value by executing the non-reversible function on the new password and comparing it to the previous value. This is the authentication test that is performed by the Second Computer Program at step 30.

This sequence of passwords S₀ ... S_n may be stored by the First Computer Program, or just the seed value which may be used to regenerate the sequence when required. The seed value S₀, may be created a number of ways, including use of a random number generator, accessing internal computer identification data, or using a character string entered by a User.

At step 32 of Figure 3, the First Computer Program initializes the password sequence by transmitting the final code in the sequence, S_n, to the Second Computer Program. Clearly, it is not required that the initial value sent to the Second Computer Program necessarily be the final code in the sequence. Any value in the sequence could be transmitted as the initial value, provided that subsequent passwords are the result of previous iterations of the non-reversible function to exploit the non-reversible property of the function. An account between two entities may be initialized in a number of ways as known in the art, as long as the initial value is received by the Second Computer Program in some manner that it may be stored as a reference for that account as shown at step 34. The Second Computer Program continually replaces the reference value with new passwords so that it contains the most recent password or initial value as a reference value as shown at step 36.

The actual authentication is effected by the First Computer Program transmitting to the Second Computer Program a password calculated by fewer iterations of the non-reversible function on the stored seed value than used to calculate the reference value, as shown at step 38. The iteration number is also stored at the First Computer Program in order to know which iteration of the sequence is required for the next password.

In the simplest form of the protocol, each password would be generated by an immediately preceding iteration of the non-reversible function. However, more complex methods of implementing this authentication are disclosed in United States Patent Application, Serial No. 09/134,731.

The Second Computer Program then receives the password from the First Computer Program at step 40. If the password is successfully authenticated by the non-reversible function operating upon it being equal to the reference value as shown at step 30, then the Second Computer Program authenticates the First Computer Program to the Second Computer Program at step 36 and stores the password as the new reference value.

If the authentication at step 30 is not successful, then an indication is made within the Second Computer Program that access is to be denied at step 42. The Second Computer Program then transmits notice to the First Computer Program of whether authentication was or was not successful at step 44, and the First Computer Program receives the notice at step 46 and proceeds with its secured session if successfully authenticated.

Clearly, the steps need not be executed in the explicit manner as described to realize the advantages of the invention. For example, one skilled in the art would know a variety of methods for storing and communicating whether the authentication attempt has been successful or not.

This method provides a number of advantages. Generally speaking, the Second Entity 16 only verifies the password against non-confidential data, and does not have to authenticate it against private credit card data as in the systems known in the art. Therefore, the Second Entity 16 does not need to store private information for each First Entity 18, and does not become a high-value target for attacks. Because so little information must be stored at the Second Entity 16, and because the processing is so straightforward, very little memory and computational overhead is required. This allows Second Entity 16 to be implemented without a huge infrastructure, and allows it to be easily scalable in the number of End Users and applications. The invention is preferably implemented so that each password may only be used once, which is described as a One-Time-Password. Therefore, there is no point in intercepting a password because it can not be used to gain access, and also provides for non-repudiation.

Because secure End User data does not have to be transmitted over the insecure network, not even in an encrypted form, there are no privacy concerns. As well, security of the network is no longer as important since there are no personal secrets to be gained during transmission.

The passwords generated by the non-reversible function may be very long and totally random, and entities do not have to "remember" their own passwords as they may be stored in a secure area of their own computer.

Although the invention could be implemented with smart cards as a security means, there is no need for it. As noted above, smart cards require an electronic interface to access the contents of their memories and are therefore less desirable than fully software based systems. Non-repudiation is an inherent feature of the one-time non-reversible passwords and no further add on is required. Therefore entities can be held to the commitments that they make. In general, this means of non-repudiation does not require the greater overhead and operational demands on the system created when the known methods are combined with known cryptographic signature techniques as described in the Background to the Invention above. Therefore, the improvement is realized without compromising speed, bandwidth, reliability and cost. As well, there are no key management problems.

Alternatively, the general method of the invention may be applied using existing password techniques. For example, once the access certificate is created, the first entity may access services from the second entity by means of a secure password that the second and first entities have agreed upon.

Similarly, each pairing of adjacent entities in said billing chain may have a trusted relationship, established by means of passwords, encrypted signatures, secure networks or other means.

The preferred embodiment of the invention will now be described with respect to the physical arrangement of Figure 4. In this implementation, an electronic commerce transaction between an End User 48 and a Service Provider 50 in an Internet environment is described. The End User 48 establishes access to an Internet network 52 via an Access Provider 54. The Service Provider 50 has a preferred Agent 56 who handles the accounting and billing issues for the Service Provider 50. This physical system is known in the art, and a skilled technician would be familiar with the hardware and software requirements to create such a network and allow the entities to intercommunicate. This physical arrangement may implement a method of the invention which parallels that of the existing manufacturer - distributor - retailer - consumer model. This model allows each entity to operate in a manner to which they are accustomed, and are prepared to manage. Similarly, manufacturer - wholesaler - distributor - retailer - consumer, or other business models may be applied to this invention. Any number of intermediate entities may be introduced with very little additional overhead, in contrast to known systems of electronic commerce.

The Access Provider 54 provides Internet access to the End User 48, invoicing the End User 48 for this and possibly other services. In the context of the above sales model, the Access Provider 54 may be viewed as the retailer. Of course, it is not strictly required that the Access Provider 54 invoice the End User 48 for services provided. The invention allows any interested entity in the billing chain to do the invoicing. For example, a telephone company may not be providing Internet access to the End User 48, but may be used as an invoicing entity by certain Service Providers 50 because it already has a credit relationship with the End User 48 and already sends monthly invoices to the End User 48.

Similarly, the End User 48 could obtain Internet access from any interested entity. If a Service Provider 50 is invoicing the End User 48 via an entity other than the Access Provider 54, it is not necessary for the Access Provider 54 to be in the billing chain. The End User 48 is the entity that accesses the Service Provider's 50 website and requests some particular service. In Figure 4, the End User 48 is represented by a desk top computer, but the hardware may be a laptop computer, personal digital assistant, Internet cellular telephone, or similar device. Technology is still evolving which combines various media such as television services, telephone services, television cable, wireless telephone, Internet telephony and telephone twisted pair, and it is clear the invention may be applied to such systems. The nature of the connection between the End User 48 and the Access Provider 54 will dictate the hardware required. Such hardware and connections are known in the art, and would include ISDN, ADSL, telephone lines and television cable systems.

The Service Provider 50 is the entity who provides the service that the End User 48 has agreed electronically to make payment for. This may be an electronic service, in the case of newspaper articles or software which may be downloaded to the End User 48, or physical products such as shoes or clothing which will be physically delivered to the End User 48. In the context of the sales model, the Service Provider 50 may be viewed as the manufacturer.

As noted in the Background to the Invention, Service Providers 50 may not have the skill, infrastructure or desire to manage the billings and accounts receivable for thousands of clients in real time when they are used to dealing with a small number of distributors on contracts which may span months or years.

The Agent 56 is the entity that assumes the management of the billings and accounts receivable, as well as other tasks that the Service Provider 50 does not wish to perform. In the context of the sales model the Agent 56 may be considered to be the distributor. Both the Service Provider 50 and Agent 56 have been presented in Figure 4 as servers, but clearly they could be implemented using other hardware.

The preferred method of creating an access certificate is described in Figure 5. In this embodiment of the invention the End User 48 will be executing a piece of computer software called an Access Client. This software executing on the End User's computer 48, securely maintains the End User's 48 access certificate(s) and delivers the relevant access certificate to the corresponding Service Provider 50 when required.

The Service Provider 50 will be executing a piece of software called an Access Control Server, which resides on the domain of the Service Provider 50. It is responsible for creating and revoking access certificates for the End User 48. It may also sort billing records from End Users 48 by identifying those destined for different Agents 56.

The Access Provider 54 and Agent 56 execute software called the Access Delegation Server, which can authenticate an access request, and generate or revoke subordinate access certificates. This software may also sort billing records from either other Access Delegation Server software or Access Control Server software, identifying billing records destined for other intermediate entities 22, 24 or End Users 48. It may also consolidate electronic payments so that payments may be forwarded to the appropriate intermediate entities 22, 24 or Service Providers 50. In this embodiment of the invention, each of End User 48, Service Provider 50, Access Provider 54 and Agent 56 are able to execute a like non-reversible function as described above.

As noted above in the description of Figure 2, it is preferred that most of the steps in generating the access certificate be performed ahead of time. This is due to the fact that the Service Provider 50, Access Provider 54 and Agent 56 will generally require formal licenses to be negotiated and executed between the respective . pairings.

The Service Provider 50 is free to identify and negotiate with various Agents 56 to serve as distributors for his products. Typically, a Service Provider 50 may have a number of Agents 56 in the same manner that manufacturers may have distribution agreements with a number of distributors. Once terms of agreement have been reached, the Service Provider 50 generates an access certificate using the access control server software, which establishes the conditions under which the Agent 56 and any of it's delegates can access the Service Provider 50. The Service Provider 50 transmits this access certificate to the Agent 56 at step 58. Embedded in the access certificate is identification of the Service Provider 50 and the Agent 56, and a one-time delegation password that shows the Service Provider 50 has generated this access certificate. The Service Provider 50 repeats the same process for each Agent 56 that it chooses to establish a service reselling agreement with. This process may be performed ahead of time, or in response to a request from an End User 48. As noted above, Agent 56 serves as the Internet distributor for one or more Service Providers 50. The Agents 56 may serve as clearinghouses, who perform billing record collation and payment collection and who will act on behalf of the Service Provider 50 to identify the End User 48 and collect the payment.

As well, if the Service Provider 50 has not yet transmitted a reference password to the Agent 56, this will also have to be done to provide the Agent 56 with a reference against which the non-reversible delegation password in the access certificate may be verified. In this manner, the Agent 56 will be able to confirm, non- repudiably, that the access certificate and its terms was generated by the Service Provider 50.

In a similar manner, Agents 56 are free to identify and negotiate with various Access Providers 54, to deliver the Service Provider's 50 products to End Users 48. Typically, Agent 56 may have agreements with a number of Access Providers 54 to deliver services in the same manner that distributors may have distribution agreements with a number of retailers, but generally there will only be one Access Provider 54 through which a given End User 48 may be reached. If the Agent 56 has not yet transmitted a reference password to a given

Access Provider 54 as part of this process, this will also have to be done to provide the Access Provider 54 with a reference against which the non-reversible password may be verified. In this manner, the Access Provider 54 will be able to confirm, non- repudiably, that the access certificate and its terms was generated by the Agent 56. The Agent 56 may also contract other intermediaries en route to the Access

Provider 54, possibly to delegate certain responsibilities and activities. For example, Agent 56 may receive a request that is beyond its capacity to handle. In such a case, it may either reject the access certificate, or delegate it to another intermediate entity 22, 24 with the capacity to handle the request. The Access Provider 54 then receives the access certificate, and using its own Access Delegation Software, authenticates the sender and reviews the terms and conditions of the access certificate. If it is acceptable, it can be forwarded to an End User 48 that requests access to the corresponding Service Provider 50. This is done by appending the identification of the End User 48 and passing the access certificate on to the End User 48 at step 62. The access certificate transmitted to the End User 48 now contains the identification of the Service Provider 50, the Agent 56, the Access Provider 54 and End User 48.

Generally, the Access Provider 54 will already have an account arrangement with the End User 48 and a credit history, and will be invoicing the End User 48 for services, for example on a monthly basis. However, the Access Provider 54 may wish to debit costs against an End User 48 account, or have authorization from the End User 48 to debit a credit card, debit card, line of credit or bank account in the event of a cost overrun. In the same way as above, the Access Provider 54 may have to provide a reference password to the End User 48 in a separate transmission to provide the End User 48 with a reference against which the non-reversible password may be verified. In this manner, the End User 48 will be able to confirm, non-repudiably, that the access certificate and its terms were generated by the Access Provider 54. The access certificate now contains the complete billing chain or in the context of the preferred embodiment, a delegation trail. The End User 48 may now use this access certificate to request services from the Service Provider 50, at step 64. When the Service Provider 50 receives the access certificate from the End User 48 along with a non-reversible password, he may authenticate the End User 48 and be assured of payment via the billing chain.

If the End User 48 requests a transaction that goes beyond the current level of authorization, the Service Provider 50 may initiate a new access certificate for the higher level of service. This new authorization would follow the same sequence as steps 58 to 64 described above. The sequence of steps 58 to 64 need only be performed once to establish a new billing chain. Once this is established, the End User 48 may use the same access certificate to purchase services from the same Service Provider 50 multiple times. With each transmission from the End User 48, a successively earlier iteration of the hash sequence generated by the non-reversible function is appended by the End User 48, authenticating himself to the Service Provider 50.

As noted above, this method minimizes the number of communications needed to authorize an electronic commerce transaction. If any party in the delegation chain does not wish to participate in the transaction, it may do so by refusing to pass the access certificate on to the next party. In such an eventuality, it is preferred that the Service Provider 50 and End User 48 be given an indication of the rejection and at what point in the billing chain the rejection took place. The End User 48 may then make an additional attempt to obtain authorization, or take corrective measures. Once the access certificate has been generated, the preferred process of Figure 6 may be executed. At step 66, the process begins when the End User 48 sends a request to the Service Provider 50 for a particular service. The Service Provider 50 determines at step 68 whether the request is for a service which it makes freely available, or one which it requires payment for. If it is a free service, control passes 'to step 70 where the service is sent to the End User 48 and the process is completed. If the Service Provider 50 requires payment for the service, control passes to step 72, where the Service Provider 50 requests a valid access certificate from the End User 48. The End User 48 then sends a request to the Access Provider 54 for an access certificate appropriate to the Service Provider 50 it wishes to access. If the Access Provider 54 determines that it does not have such an access certificate at step 76, it may initiate a process to obtain one by querying various Agents 56, however, as noted above, it is expected that negotiation of such license agreements generally can not be made in an automated environment as it requires execution of contracts and licenses. However, the invention does not preclude such an arrangement. Therefore, the Access Provider 54 will generally return a failure notice to the End User 48 at step 78. If the Access Provider 54 does have a suitable access certificate, it will append the identification of the End User 48 to it and forward it to the End User 48 at step 80. The End User 48 may then pass the access certificate on to the Service Provider 50 which verifies the access certificate at step 82 and forwards the service at step 70.

In general, a non-reversible password is also forwarded with each communication so that the identity of each entity may be verified, and the actions non-repudiated.

The process for collecting the outstanding payments follows logically from the method of Figure 5, and is presented in Figure 7. This method comprises two separate processes: the billing process and the payment process. The transfer of information in the billing process is identified in Figure 7 by solid lines, while the payment process is identified by hatched lines.

As indicated above, the Service Provider 50 may request a settling of accounts through the billing chain whenever he requires. As one of the purposes of the invention is to reduce the overhead to the Service Provider 50, it is expected that the settling of accounts will only be initiated on a weekly or monthly basis. The Service Provider 50 initiates the billing process by collating transactions that passed through a particular Agent 56, and transmitting the corresponding billing records to that Agent 56 at step 84. Each billing record will be accompanied by an access certificate so that the entities in the billing chain will know how to route the billing record to obtain compensation, and can authenticate those records.

The Agent 56 in turn collates the invoices it receives from various Service Providers 50, and transmits those billing records on to their respective Access Providers 54 at step 86.

The Access Providers 54 in turn, collate the billings they receive from various Agents 56 for each End User 48, and forward invoices to the End Users 48 at step 88. As noted above, the Access Providers 54 will generally have accounts and billing arrangements already established for each End User 48. In a simple implementation, this relationship may comprise an Access Provider 54 mailing an invoice to an End User 48 which he pays at a bank. Even if the Access Provider 54 obtains payment from the End User 48 electronically at step 90, the method of the invention will make this a secure transaction. Because the Internet passes data from one network, server or computer, to the next, private credit data would have to pass through dozens of entities for each transaction using known electronic commerce methods. If an End User 48 is accessing several sites a day, his personal data may pass through millions of Internet entities in the course of a year. However, in the invention, the End User 48 need only transfer his credit card data to the Access Provider 54 via his modem and telephone line. This connection is not an Internet connection, but a private communication. Therefore the End User's 48 data does not pass through the hands of any other Internet entities, and can not be intercepted in that manner.

In the future, telephone services may employ Internet protocol and networks as part of their infrastructure, so the communication between the End User 48 and the Access Provider 54 may not be a secure communication. However, the invention may be implemented with the End User 48 sending his credit data to the Access Provider 54 electronically only once, to set up an account, which would be far less exposure than the existing systems which may expose this credit card data in the order of millions of times over the course of a year. This information may also be transferred to the Access Provider 54 manually, with no exposure to the Internet at all, sending the account information by mail or voice telephone call, or by hand at a store front. Because the information only has to be sent once, it would not be an excessive burden on the Access Provider 54 to handle this transaction manually.

The Access Provider 54 collects payment from End Users 48 and consolidates payment to send to the Agent 56 at step 92. The Agent 56 in turn consolidates payments from all Access Providers 54 and sends payment to the

Service Provider 50 at step 94. These transactions may be made securely by use of the one-time passwords described above.

Using the non-reversible one-time passwords described above, the Service Provider 50 no longer needs to have direct knowledge of individual subscribers and generate individual bills for each and everyone. For a large number of subscribers, this is a significant business overhead. At the same time, the Service Provider 50 can uniquely and yet anonymously identify End Users 48 for the purpose of billing. Usage by End Users 48 covered by corporate agreements can also be tracked on behalf of the corporation for the purpose of corporate cost recovery with very little additional overhead.

With the existing technology, Service Providers 50 either knows the identity of all of it's subscribers or none, since the billing is done either via a corporate purchase order, or an individual payment scheme such as credit card. For corporate level service agreements, Service Providers 50 no longer need to be content with the practice of using a single user identification or password access for the whole company. That is currently done to reduce administrative overhead.

The Service Provider 50 will be able to track usage pattern of all End Users 48 anonymously to achieve accurate profiling of usage without requiring End Users 48 to reveal any information. The only entity who is aware of the End User's 48 identity is the Access Provider 54, from whom the End User 48 acquires access to the Internet.

The invention may also be used to establish an electronic billing network across multiple commercial domains for the purpose of generating billing information where the creator of the bill need not know who the ultimate recipient of the bill may be. This is done by providing each entity in the billing chain with an assurance of payment from all parties in the billing chain. The invention may also be applied with numerous alternative embodiments. These would include:

1. Variations to hash functions:

A large number of additional variations to the application of the hash sequence are described in the co-pending application under United States

Patent Application, Serial No. 09/134,731. The applicability of these variations are clear from the teachings herein.

2. Additional Intermediaries:

The invention is not limited by the number of intermediaries or what functions they perform. The invention allows, for example, Fan web sites with links to

Service Providers 50 to receive monetary credit for transactions executed by End Users 48 that the fan site attracts. The payment from the Service Provider 50 to the Fan web site may also be executed using the method of the invention. An End User 48 may be looking at a Fan web site for a certain musician which is linked to a record producer. If the End User 48 wishes to purchase an electronic file of a song by that musician, then the transaction between the End User 48 and the record producer is performed in the same manner as described above, where the record producer is the Service Provider 50. The record producer then processes a credit invoice through the intermediary and

Access Provider 54 of the Fan web site.

3. Bundled Services:

Agents 56 and Access Providers 54 may offer bundles of services to End Users 48 to further simplify the provision of services. The consolidation of services may be made at either the Agent's 56 level, or the Access Provider's

54 level. For example, an Agent 56 may offer a "current events" package which allows End User's 48 to access a group of news, newspaper and magazine web sites represented by the Agent 56, and forward a corresponding group of access certificates to the End User 48. Similar packages could be offered which bundle computer games, technical journals, sports memorabilia, or other items. Invoicing may be made in a number of manners including, for example, pay-for-use, or payment of a base cost for the entire package. This approach is an added convenience for the End User 48 and the Access Provider 54 as the End User 48 only has to make one request to his Access Provider 54 for the entire package, rather than once for each related service he wishes to access. Clearly, an End User 48 could also obtain bundles from a number of different entities, including an Access Provider 54, or an

Agent 56. 4. Access Certificate:

The routing and conditions of an access certificate could be predetermined by the Service Provider based on information queried from the End User and/or its own requirements. If each entity was party to a standing agreement, it would not be necessary to route the initial access certificate through each entity in the billing chain for its approval.

This situation may arise for example, where the Access Provider 54 is providing a service to the End User 48. 5. Negotiating Profit Sharing:

The distribution of the profits between entities could be one of the parameters included in the access certificate. In such a case, it would be desirable to encrypt the profit data in some manner so that other entities would not be able to identify this data. While particular embodiments of the present invention have been shown and described, it is clear that changes and modifications may be made to such embodiments without departing from the true scope and spirit of the invention. For example, rather than an End User purchasing shoes from a Service Provider's web site, the invention could be equally employed to the execution of a merger between two large companies, or the ordering and distribution of stationary products within a large company.

It is understood that as communication networks become more flexible and powerful, the definitions of servers, computers, LANs, WANs and other hardware components are becoming less and less clear. These terms have been used herein to simplify the discussion and do not strictly limit the invention to the former definitions of such hardware. Similarly, telephony hardware is beginning to perform more intelligent control of data communications. Again, implementing the invention with such telephony hardware clearly does not take away from the invention. The method steps of the invention may be embodiment in sets of executable machine code stored in a variety of formats such as object code or source code. Such code is described generically herein as programming code, or a computer program for simplification. Clearly, the executable machine code may be integrated with the code of other programs, implemented as subroutines, by external program calls or by other techniques as known in the art.

The embodiments of the invention may be executed by a computer processor or similar device programmed in the manner of method steps, or may be executed by an electronic system which is provided with means for executing these steps. Similarly, an electronic memory means such computer diskettes, CD-Roms, Random Access Memory (RAM) and Read Only Memory (ROM) may be programmed to execute such method steps. As well, electronic signals representing these method steps may also be transmitted via a communication network.

It would also be clear to one skilled in the art that this invention need not be limited to the existing scope of computers and computer systems.

Credit, debit, bank and smart cards could be encoded to apply the invention to their respective applications. An electronic commerce system in a manner of the invention could for example, be applied to parking meters, vending machines, pay telephones, inventory control or rental cars and using magnetic strips or electronic circuits to store the software and passwords. Again, such implementations would be clear to one skilled in the art, and do not take away from the invention.

Claims

WHAT IS CLAIMED IS:

1. A method of performing an electronic commerce transaction between a first entity and a second entity via one or more intermediate entities over a communication network, said method comprising the steps of: generating an access certificate describing a billing chain and including the identification of each said entity in said billing chain; at said first entity, transmitting said access certificate to said second entity; and at said second entity, accepting said access certificate as assurance of payment and providing a service to said first entity.

2. A method of performing an electronic commerce transaction as claimed in claim 1 , wherein said step of generating an access certificate describing a billing chain comprises the step of: generating an access certificate describing a billing chain, including the identification of each said entity in said billing chain, and describing the rights being delegated to said first entity.

3. A method of performing an electronic commerce transaction as claimed in claim 2, wherein each of said entities is operable to execute a like non-reversible function, further comprising the steps of: at each of said entities: generating a hash sequence by executing said non-reversible function on a seed value; transmitting a first hash value in said hash sequence to a said adjacent entity; and appending a second hash value in said hash sequence to said access certificate, said second hash value being generated by fewer executions of said non-reversible function than said first hash value.

4. A method of executing an electronic commerce transaction as claimed in claim 3, further comprising the steps of: at each of said entities: authenticating said access certificate by verifying that said first hash value of said adjacent entity is equal to said second hash value of said adjacent entity operated upon by said non-reversible function.

5. A method of performing an electronic commerce transaction as claimed in claim 2 wherein said step of said second entity accepting said access certificate as assurance of payment and providing a service to said first entity comprises the step of said second entity accepting said access certificate and a secure password from said first entity as assurance of payment and providing a service to said first entity.

6. A method of performing an electronic commerce transaction as claimed in claim 2 wherein said step of generating an access certificate comprises generating an access certificate describing a billing chain and including the identification of each said entity in said billing chain, each pairing of adjacent entities in said billing chain having a trusted relationship.

7. A method of performing an electronic commerce transaction as claimed in claim 4, wherein said step of generating an access certificate comprises the steps of: at said second entity: generating an access certificate including the identification of an adjacent intermediate entity and describing the rights being delegated to said first entity; and transmitting said access certificate to said adjacent intermediate entity in a billing chain; until reaching an intermediate entity adjacent to said first entity in said billing chain, repeating for each intermediate entity the steps of: responding to receipt of said access certificate and agreeing to its terms by: appending the identification of the next adjacent intermediate entity in said billing chain to said access certificate; and transmitting said access certificate to said next adjacent intermediate entity in said billing chain; and at said intermediate entity adjacent to said first entity in said billing chain, responding to receipt of said access certificate and agreeing to its terms by: appending the identification of said first entity to said access certificate; and transmitting said access certificate to said first entity; whereby said access certificate describes a billing chain, including the identification .of each said entity in said billing chain, and describing the rights being delegated to said first entity.

8. A method of performing an electronic commerce transaction between an End

User and a Service Provider via an Access Provider and an Agent in an Internet network, each of said End User, said Service Provider, said Access Provider and said Agent being operable to execute a like non-reversible function, said method comprising the steps of: at said End User, transmitting a request for a service to said Service Provider; at said Service Provider, responding to said service request being for a pay service by requesting an access certificate from said End User, said access certificate describing a billing chain and including the identification of said

Service Provider and said End User, and describing the rights being delegated to said End User; at said End User responding to said access certificate request and not having a said access certificate for said Service Provider by: requesting said access certificate for said Service Provider from said Access Provider; and at said Access Provider, responding to said request for said access certificate for said Service Provider by returning said access certificate for said Service Provider to said End User if one is available, otherwise, return a failure indication; at said End User, responding to either receipt of said access certificate from said

Access provider, or already having a said access certificate for said Server

Provider by: generating a hash sequence by executing said non-reversible function on a seed value; transmitting a first value in said hash sequence to said Service Provider; and appending a second value in said hash sequence to said access certificate, said second value being generated by fewer executions of said non- reversible function than said first value and transmitting said access certificate to said Service Provider when said service is required; and at said Service Provider, responding to receipt of said access certificate by: responding to said first value being equal to said second value when operated upon by said non-reversible function, by providing said service to said End User.

9. A method of performing an electronic commerce transaction between a first entity and a second entity via one or more intermediate entities over a communication network, said method comprising the steps at said second entity of: accepting an access certificate describing a billing chain and including the identification of each said entity in said billing chain, received from a first entity along with a service request as assurance of payment; and providing said service to said first entity.

10. A method of performing an electronic commerce transaction as claimed in claim 9, wherein said step of accepting an access certificate describing a billing chain comprises the step of: accepting an access certificate describing a billing chain, including the identification of each said entity in said billing chain and describing the rights being delegated to said first entity, received from a first entity along with a service request as assurance of payment.

11. A method of performing an electronic commerce transaction as claimed in claim 10, wherein each of said entities is operable to execute a like non-reversible function, further comprising the step of: authenticating said access certificate by verifying that said first hash value of said adjacent entity is equal to said second hash value of said adjacent entity operated upon by said non-reversible function.

12. A method of performing an electronic commerce transaction as claimed in claim 11 , further comprising the steps at said second entity of: generating an access certificate including the identification of an adjacent intermediate entity and describing the rights being delegated to said first entity; and transmitting said access certificate to said adjacent intermediate entity in a billing chain.

13. A method of performing an electronic commerce transaction between an End User and a Service Provider via an Access Provider and an Agent in an Internet network, each of said End User, said Service Provider, said Access Provider and said Agent being operable to execute a like non-reversible function, said method comprising the steps at said Service Provider of: responding to a service request from said End User being for a pay service by requesting an access certificate from said End User, said access certificate describing a billing chain, including the identification of said Service Provider and said End User, and describing the rights being delegated to said End User; and responding to receipt of said access certificate by: responding to said first value being equal to said second value when operated upon by said non-reversible function, by providing said service to said End User.

14. A method of performing an electronic commerce transaction between a first entity and a second entity via one or more intermediate entities over a communication network, said method comprising the steps at said first entity of: transmitting an access certificate describing a billing chain and including the identification of each said entity in said billing chain to said second entity.

15. A method of performing an electronic commerce transaction as claimed in claim 14, wherein said step of transmitting an access certificate describing a billing chain comprises the step of: transmitting to said second entity, an access certificate describing a billing chain, including the identification of each said entity in said billing chain, and describing the rights being delegated to said first entity.

16. A method of performing an electronic commerce transaction as claimed in claim 15, wherein each of said entities is operable to execute a like non-reversible function, further comprising the steps prior to said step of transmitting, of: generating a hash sequence by executing said non-reversible function on a seed value; transmitting a first hash value in said hash sequence to said second entity; and appending a second hash value in said hash sequence to said access certificate, said second hash value being generated by fewer executions of said non- reversible function than said first hash value.

17. A method of performing an electronic commerce transaction between an End User and a Service Provider via an Access Provider and an Agent in an Internet network, each of said End User, said Service Provider, said Access Provider and said Agent being operable to execute a like non-reversible function, said method comprising the steps of: transmitting a request for a service to said Service Provider; responding to said access certificate request and not having a said access certificate for said Service Provider by requesting said access certificate for said

Service Provider from said Access Provider; said access certificate describing a billing chain, including identification of the said

Service Provider and said End user, and describing the rights being delegated to said End User; and responding to either receipt of said access certificate from said Access Provider, or already having a said access certificate for said Server Provider by: generating a hash sequence by executing said non-reversible function on a seed value; transmitting a first value in said hash sequence to said Service Provider; and appending a second value in said hash sequence to said access certificate, said second value being generated by fewer executions of said non- reversible function than said first value and transmitting said access certificate to said Service Provider when said service is required.

18. A system for executing an electronic commerce transaction between a first entity and a second entity, said system comprising: a first entity; a second entity; one or more intermediate entities; said first entity, said second entity and said one or more intermediate entities operable to communicate via a communication network; each said entity being operable to participate in generating an access certificate describing a billing chain and including the identification of each said entity in said billing chain; said first entity being operable to transmit said access certificate to said second entity; and said second entity being operable: to accept said access certificate as assurance of payment; and to provide a service to said first entity.

19. A system as claimed in claim 18, wherein each said entity being operable to participate in generating an access certificate describing a billing chain and including the identification of each said entity in said billing chain further comprises: each said entity being operable to participate in generating an access certificate describing a billing chain, including the identification of each said entity in said billing chain, and describing the rights being delegated to said first entity.

20. A system as claimed in claim 19, wherein each of said entities is operable to: execute a like non-reversible function; generate a hash sequence by executing said non-reversible function on a seed value; transmit a first hash value in said hash sequence to a said adjacent entity; and append a second hash value in said hash sequence to said access certificate, said second hash value being generated by fewer executions of said non- reversible function than said first hash value.

21. A system as claimed in claim 20, wherein each said entity is further operable to: authenticate said access certificate by verifying that said first hash value of said adjacent entity is equal to said second hash value of said adjacent entity operated upon by said non-reversible function.

22. A system as claimed in claim 19 wherein said second entity being operable to accept said access certificate as assurance of payment comprises said second entity being operable to accept said access certificate and a secure password from said first entity as assurance of payment.

23. A system as claimed in claim 19 wherein each said entity being operable to participate in generating an access certificate describing a billing chain and including the identification of each said entity in said billing chain comprises: each said entity being operable to participate in generating an ∞^ -i J|i5f^ describing a billing chain and including the identification of each said entity in said billing chain, each pairing of adjacent entities in said billing chain having a trusted relationship.

24. A system as claimed in claim 21 , wherein said second entity is operable to: generate an access certificate including the identification of an adjacent intermediate entity and describing the rights being delegated to said first entity; and transmit said access certificate to said adjacent intermediate entity in a billing chain; each said intermediate entity is operable to, until reaching an intermediate entity adjacent to said first entity in said billing chain, respond to receipt of said access certificate and agreeing to its terms by: appending the identification of the next adjacent intermediate entity in said billing chain to said access certificate; and transmitting said access certificate to said next adjacent intermediate entity in said billing chain; and said intermediate entity adjacent to said first entity in said billing chain is operable to respond to receipt of said access certificate and agreeing to its terms by: appending the identification of said first entity to said access certificate; and transmitting said access certificate to said first entity; whereby said access certificate describes a billing chain, including the identification of each said entity in said billing chain, and describing the rights being delegated to said first entity.

25. A system for executing an electronic commerce transaction between an End

User and a Service Provider, said system comprising: an End User; a Service Provider; an Access Provider; an Agent; an Internet network interconnecting said Service Provider, said Access Provider and said Agent; said Access Provider providing Internet access for said End User; said End User being operable to transmit a request for a service to said Service

Provider; said Service Provider being operable to respond to said service request being for a pay service by requesting an access certificate from said End User; said access certificate describing a billing chain and including the identification of said Service Provider and said End User, and describing the rights being delegated to said End User; said End User being operable to respond to said access certificate request and not having a said access certificate for said Service Provider by: requesting said access certificate for said Service Provider from said Access Provider; and said Access Provider being operable to respond to said request for said access certificate for said Service Provider by returning said access certificate for said Service Provider to said End User if one is available, otherwise, return a failure indication; said End User being operable to respond to either receipt of said access certificate from said Access Provider, or already having a said access certificate for said

Server Provider by: generating a hash sequence by executing said non-reversible function on a seed value; transmitting a first value in said hash sequence to said Service Provider; and appending a second value in said hash sequence to said access certificate, said second value being generated by fewer executions of said non- reversible function than said first value and transmitting said access certificate to said Service Provider when said service is required; and said Service Provider being operable to respond to receipt of said access certificate by: responding to said first value being equal to said second value when operated upon by said non-reversible function, by providing said service to said End User.

26. A computer readable storage medium storing ^"a set of machine executable code, said machine executable code being executable by a computer server to perform the steps of: accepting an access certificate describing a billing chain and including the identification of each said entity in said billing chain, received from a first entity along with a service request as assurance of payment; and providing said service to said first entity.

27. A computer readable storage medium as claimed in claim 26, wherein said step of accepting an access certificate describing a billing chain comprises the step of: accepting an access certificate describing a billing chain, including the identification of each said entity in said billing chain and describing the rights being delegated to said first entity, received from a first entity along with a service request as assurance of payment.

28. A computer readable storage medium as claimed in claim 27, further comprising the step of: authenticating said access certificate by verifying that a first hash value previously forwarded by said entity forwarding said access certificate is equal to a second hash value attached to said access certificate, when operated upon by said non-reversible function; said first and second hash values being generated by a non-reversible function.

29. A computer readable storage medium as claimed in claim 28, further comprising the prior steps of: generating an access certificate including the identification of an adjacent intermediate entity and describing the rights being delegated to said first entity; and transmitting said access certificate to said adjacent intermediate entity in a billing chain.

30. A computer readable storage medium storing a set of machine executable code, said machine executable code being executable by a Service Provider computer server to perform the steps of: responding to a service request from an End User being for a pay service by requesting an access certificate from said End User, said access certificate describing a billing chain, including the identification of said Service Provider and said End User, and describing the rights being delegated to said End User; receiving a first hash value from said End User generated by a non-reversible function; and responding to receipt of said access certificate from said End User by: responding to said first hash value being equal to a second hash value when operated upon by said non-reversible function, by authenticating said End User and providing said service to said End User.

31. A computer readable storage medium storing a set of machine executable code, said machine executable code being executable by a computer to perform the steps of: transmitting an access certificate describing a billing chain and including the identification of each said entity in said billing chain to said second entity.

32. A computer readable storage medium as claimed in claim 31 , wherein said step of transmitting an access certificate describing a billing chain comprises the step of: transmitting to said second entity, an access certificate describing a billing chain, including the identification of each said entity in said billing chain, and describing the rights being delegated to said first entity.

33. A computer readable storage medium as claimed in claim 32, further comprising the steps prior to said step of transmitting, of: generating a hash sequence by executing said non-reversible function on a seed value; transmitting a first hash value in said hash sequence to said second entity; and appending a second hash value in said hash sequence to said access certificate, said second hash value being generated by fewer executions of said non- reversible function than said first hash value.

34. A computer data signal embodied in a carrier wave, said computer data signal comprising a set of machine executable code being executable by a computer to perform the steps of: transmitting an access certificate describing a billing chain and including the identification of each said entity in said billing chain to said second entity.

35. A computer data signal as claimed in claim 34, wherein said step of transmitting an access certificate describing a billing chain comprises the step of: transmitting to said second entity, an access certificate describing a billing chain, including the identification of each said entity in said billing chain, and describing the rights being delegated to said first entity.

36. A computer data signal as claimed in claim 35, further comprising the steps prior to said step of transmitting, of: generating a hash sequence by executing said non-reversible function on a seed value; transmitting a first hash value in said hash sequence to said second entity; and appending a second hash value in said hash sequence to said access certificate, said second hash value being generated by fewer executions of said non- reversible function than said first hash value.