Electronic Commerce on the Internet: What Is Still Missing?
In this paper we investigate those aspects of electronic commerce which can be used to facilitate inter-organisational business dealings. The Internet has substantially promoted different aspects of electronic commerce such as electronic ordering and shopping: electronic malls are increasingly becoming part of the modern information society. However, the pace of adoption of emerging computing and communication technologies for electronic business dealings between enterprises is much slower. We argue that, among other reasons, two major factors for this are: i) an inadequate representation of the semantics of business activities and ii) the lack of a sound legal support for electronic interactions. We propose a general framework for business contracts that addresses both of these issues and investigate how this framework can be used in the context of the Internet.
Electronic commerce is a broad term which covers a wide range of commercial activities that are performed by means of an electronic web that can connect trading partners. Until recently electronic interactions have been the privilege of large companies which had the knowledge, technology and sufficient capital to invest in an electronic infrastructure that supports electronic business transactions. Examples are financial institutions (e.g. banks), airline carriers, some manufacturing companies and large retail distributors. Additional impetus for increased electronic business transactions over the last several years have come from the Electronic Data Interchange (EDI) standards. These standards cover the communication of business information in a standardised electronic form.
The increased penetration of the Internet, its accessibility to a wider user community, and the applications such as WWW browsers (e.g. NCSA Mosaic) have provided an impetus towards an increased inroad of electronic commerce into the community at large. The emerging electronic commerce activities on the Internet such as advertising of products and services, electronic shopping, electronic malls and many other services that appear almost daily on the Internet, are the best indicator that doing electronic commerce on the Internet proves attractive and reveals new opportunities for individuals and businesses.
Consequently, it can be said that electronic commerce includes EDI, but also mechanisms to support inter-personal (human to human) communications, the transfer of moneys, and the sharing of common data bases as additional activities that aid in the efficient conduct of business [1].
While the Internet has substantially promoted different (though simple) aspects of electronic commerce, the rate with which electronic commerce has been adopted within inter-organisation business dealings is relatively slow. Yet, today's trend toward increased global interdependencies between businesses requires a modern electronic infrastructure to support these transactions. It is intuitively clear that the latter issues involve higher complexity, more uncertainty and thus potentially increased economic losses; unless there are assurances for a more coherent and, from the legal point of view, valid electronic business dealings. This paper can be regarded as an attempt to provide a basis for establishing those assurances, related to the operations associated with business contracts. We develop a general business contract framework, which can be applied to any business setting, or to any specific IT scenario. This model is then used in the context of the Internet.
In section 2, we outline different stages in the evolution of electronic commerce. The aim of this is to highlight the role of EDI, the emerging trend towards using EDI over the Internet and those concerns which still need to be addressed in order to provide a basis for a more rapid adoption of electronic commerce within electronic dealings between enterprises. In section 3, we develop a generic business contract framework, based on the understanding of contracts from economics, legal and business perspectives. This will be then applied to the specifics of the Internet environment (section 4). Conclusions and future research directions are outlined in section 5.
It is recognised that a coherent support for electronic commerce requires three fundamental sets of technological components (Fig.1), as stated in [2].
We study the evolution of electronic commerce in terms of these three elements, with the aim of identifying those components that are still missing for integrated electronic commerce activities; in particular those that refer to a wider use of electronic commerce for establishing electronic business relationships between firms.
It can be said that the first electronic commerce attempts have been made within the transportation (e.g. ocean, motor, air and rail) carriers and the associated shippers, brokers, customs, freight forwarders and bankers [3]. In fact, these were the first EDI systems, based on the use of VANs.
The strategic importance of EDI systems have been recognised from the early days. This refers not only to operational issues such as reducing paper flow and shortening times needed for execution of transactions, but also extending the business scope of enterprises, as shown in [2]. This lead to the standardisation of EDI. At the international level, such a standard is set under the auspices of the United Nations, and is called EDIFACT: EDI for Administration, Commerce and Trade [4]. In the United States, the EDI standard is developed by American National Standards Institute (ANSI) within the task group X.12. These two standards have contributed to the significant number (30-40 thousands) of organisations that presently use EDI [1]. Examples abound where companies have gained new business opportunities through EDI. These benefits include an increase in operation efficiency (both intra and inter-organisational) as well as the business scope expansion.
It is now recognised that EDI systems, which are predominantly based on proprietary information systems and VANs, can bring further advantages if implemented via the Internet. The wide penetration of the Internet enables a broader range of businesses which can utilise networking technology for their business dealings. This includes small and medium size companies, as opposed to the scenario of the past whereby only large corporations could afford such as facility. It also provides a cheaper transport facility to companies who have already been involved in EDI and who might have been using expensive dedicated VPN resources.
In addition to the increased types of business on the net, the Internet can provide more flexibility in terms of i) locating suitable and competent business partners and ii) establishing short-term business relationships between enterprises (due to large costs of setting up a VAN for traditional EDI only long-term relationships could be justified).
These factors have contributed to an initial work for facilitating traditional EDI over the Internet. For example, work has recently started to permit formatted business interchanges to be encapsulated within MIME(1) messages [5]. In the case of EDI, a message formatted according to the MIME-EDI specification could be automatically transferred to an EDI processing program [1].
The support for EDI over the Internet can be regarded as a short-term goal of electronic commerce over the Internet. A longer term goal would involve support for the semantics of business scenarios, many of which are also standardised (for cost reasons, as in the case of standardised contracts) as well support for legally valid business transactions.
For example, in setting up EDI relationships, companies presently still use paper documents. This frequently involves a lengthy process of agreement on several issues such as the EDI messages to be used. As a result, entry barriers for use of EDI are still high [6].
Some attempts have been made to assist the negotiation of EDI rules (e.g. Uniform Rules of Conduct for Interchange of Data by Teletransmission, known as UNCID, developed through the cooperation of many organisations). Another important effort in this direction is an ISO initiative, known as open-edi [7]. It has initiated work on specifying standard business scenarios that can be employed without prior trader partner agreements [6].
These issues belong to the enterprise model of electronic business dealings. In this paper we make an initial attempt to address one such enterprise issue; a support for the operations associated with establishing business contracts and monitoring and enforcing behaviour of the parties to contracts. This will be done by applying a generic business contract framework developed in [8] to the specifics of inter-organisational electronic business dealings over the Internet.
In our previous work we have extensively studied the roles and main principles associated with contracts, by taking into account economic, legal and business viewpoints. This work lead to the development of a generic business contract framework (BCF) which can be applied to any business or IT scenario [8]. In the following subsections, we will summarise the main points related to the operations of contracts in the real world and the associated concepts of our BCF.
Contracts involve a relationship between two or more parties, representing an agreement that govern their interactions. From an economic standpoint, a contract arises as a result of efficiency-seeking behaviour in a world of limited information [9]. From a legal standpoint, a contract serves to alleviate mistrust in a world of uncertainty, e.g. by constraining the unpredictable activities of the other autonomous parties. In the world of business, a contract is a major concept of business law(2). A contract is a mutually binding agreement between two or more parties to perform or not perform certain acts.
In the real world, various legislative bodies place restrictions on the contracts that can be made within their boundaries which define the contract domain. The contract domain can be determined on a regional basis (e.g. by the legislative bodies of countries or states), but also based on other criteria. For example, these can be related to a particular industry such as a specific field of trade (e.g. as defined by the international bodies which prescribe stock market trading rules), or to a particular profession (e.g. as defined by certain professional bodies(3)). The rules and policies of a particular business contract domain normally emanate from statutory or administrative law.
Interactions between parties belonging to different contract domains are normally governed by a set of policies which apply across domains, and thus define a higher-level domain. An example of a set of rules and policies which define such a domain is the United States Uniform Commercial Code, i.e. a uniform statute adopted in whole or in part by each state legislature in the US to govern specified fields of commerce.
According to the above, an architectural notion of contract domain must include:
While there is a variety of different types of contracts that govern specific relationships between trading partners (and which reflect different economic and legal factors [11]), a large class of contracts are also standardised to reduce the cost of setting up the contract agreement. This, along the fact that there are a number of elements which are common to many contracts, served as our motivation to introduce the concept of contract template in our BCF. The contract template defines a particular class of contracts. Generally, it specifies:
A contract template thus contains certain semantics of a business contract. These semantics can represent different scenarios associated with business contracting. Additionally, there can be certain relationships between different types of contracts. For example, a general contract template may require further refinement to specialise the template into a specific business contract.
To store different contract types within a BCF, and represent different relationships between them (e.g. subtype or substitutability), an appropriate repository is needed. In addition to being a storing facility, such a repository should also provide operations to manipulate contract templates. This can be particularly useful in selecting contract templates and supporting contract negotiation, as will be shown in the following sections. One example of how this can be realised in the context of open distributed systems (based on the use of a binding(4) types) has been presented in [8].
Contract negotiation is a multistep process (of offers and counter-offers), in which parties with conflicting interests come to a mutual assent, regarding the terms and conditions of the contract. Once a contract is successfully negotiated, it can be submitted by any party (or parties) to a legal expert or authority for validation.
In terms of our BCF, contract negotiation involves interaction between the potential parties to the contract. This process is influenced by the characteristics of the parties and their environment. For example, the negotiation can be performed either directly by the parties or via a third party (e.g. a broker). While in the former case, negotiation procedures are part of an application domain, in the latter case, an architectural component, a trusted broker can be used. Since, like in real life, brokers can have more information about other parties and the environment, they can reduce uncertainty about the outcome of the negotiation and provide a more efficient negotiation process.
In relation to the concept of contract templates, negotiation can be regarded as the refinement of a contract template into a (mutually agreeable) contract. Once an agreed upon contract is checked for validity, it may be stored in a notary, for use as evidence of agreement in the contract validation and enforcement activities.
In the real world, the legal system determines the validity of contracts by identifying the mandatory elements. Typically these include [10]:
A court will enforce a contract if it meets the four requirements [10]. In general, enforcement of contracts will only occur if the contract is breached by a party to that contract.
When translating these concepts into the concepts of a BCF, contract validation can be defined as the process of ensuring that a contract satisfies the above contract validity rules of the nominated contract domain. This process involves a number of steps as will be shown in the example below. The contract validity rules can require that the parties must be members of the domain (i.e. the domain administration has some control over the activities of parties).
It is worth noting that contract validation does not need to be used at each contract establishment procedure. For example, once the parties to the contract have established a contractual relationship, they both deal with legally valid contracts. This may be exploited in subsequent contract negotiations/renegotiations (a cache mechanism can be used to store such validated contract instances).
Contract monitoring is the process of observing the activities of the parties that are governed by a contract, with the aim of ensuring that those activities correspond to the contract.
Contract monitoring can be performed by:
Contract monitoring can be a continual process or it might occur only from time to time (e.g. customer satisfaction surveys).
Since quality can represent an important element of a contract, some mechanisms for the monitoring of quality of service specified in contracts need to be employed. We assume that such mechanisms will be available and can be used to support the behaviour of the parties to the contract.
If contract monitoring indicates that the contract has not been honoured by another party, the damaged party might wish to take corrective action. This process of contract enforcement can take many forms (possibly more than one):
Contract enforcement might occur through direct discussion between the contract participants. If this does not produce a satisfactory resolution, the dispute can escalate through various levels of mediation or arbitration, ultimately leading to a court case.
In terms of a BCF, contract enforcement can be pro-active, ensuring that actual behaviour conforms to the contract, or reactive, ensuring corrective actions to minimise the deviation from the contract. Corrective actions might be performed by the parties of the contract, or by some external component within the contract domain.
The effectiveness of contract enforcement might be limited if some of the parties are outside the contract domain (which is why domain membership might be required for a valid contract). If a party outside the domain does not comply with the enforcement, then the ultimate sanction of the domain is to exclude that party from the domain or from contracts within the domain in future.
We will now turn to illustrate the operations of the BCF identified so far with an example which closely resembles the typical contract operations within a legally valid contract framework. The aims of this example are to i) illustrate a temporal order of these operations and ii) the parties involved. Note that the order of steps in this example reflects one of many possible scenarios.
During the contract establishment phase (Fig. 2), it may be required that the checking of the own competence of the parties be done before contract negotiation commences (step a). This is similar to the real world scenarios, whereby often certain assurance credentials (e.g. licensing and endorsement) are required as the first element in a contract establishment. This normally means that the party has entered the contract domain.
The negotiation process starts with say party2 offering an initial contract offer (step b). Before the party1 seriously considers the offer, it may want to check the competence of the party2 (step c). If successful, the party1 can either accept the offer or submit a counter-offer (step d). The negotiation process can proceed for example with the party2 checking the validity of the counter-offer (e.g. legal validity and consideration elements, as depicted in the figure), step e. If successful, party2 can then submit a final offer. If checked for legality (step f) and accepted by party1 (step g), this contract will have a legally valid status.
The performance of the parties to the contract involves monitoring of their activities and enforcing decisions if there is non-performance to the contract (Fig.2.). After the expiry of the contract some enforcing decisions still can be done, as also depicted in the figure.
Having explained the main steps involved, we now turn to the description of the roles and the relationships between the components of the BCF as shown in Fig. 3. It is assumed that each of the concepts identified so far is assigned the roles of the corresponding BCF component, irrespective of implementation details (e.g. whether these components are centralised or distributed). It is also assumed that an architecture which would be based on such a BCF will be built on a set of security components which provide support for procedures such as authentication, authorisation and encryption.
The rules and policies of a particular legislative domain can be stored in a repository, which we term a legal rules repository (LRR), Fig. 3.
The relationship 1, between a party to the contract and a contract validator (CV) component involves a contract validity checking procedure, in which a potential party to a contract expresses its willingness to enter into a contractual relationship (at some stage in future). Thus the competence aspect of a contract should be first checked during the contract establishment phase.
Relationship (2) represents a set of contract negotiation operations between the parties to the contract. During this stage the parties can exchange several contract templates, which represent a set of offers and counter-offers, as depicted in Fig. 3. Contract negotiation can be supported by a contract negotiator (CN) component (relationship 2'). It has a mediation (brokerage) role, as discussed in subsection 3.3.
During the negotiation phase, the negotiated contract template can be submitted for further validity checking, as also discussed in the previous example. This is depicted by relationship 3 between a party to the contract and the CV and involves one or more of the following procedures.
After the contract element types are checked for the validity, during contract establishment (and stored in notary, if required), either party may request to check whether the contractual obligations have been met during the contract performance. This represents checking whether the consideration validity element of contract is met; this deals with values that one party gives/takes and thus there should be a means to monitor these parties' contract performances (relationship 4). A corresponding contract monitor (CM) component(5) can be used to monitor the activities of the parties to the contract. This includes recording the actions and measuring the performance of the parties to the contract (relationship 4) and dealing with non-performance of parties, e.g. signalling this to the contract enforcer (CE) (relationship 5).
Once the CE has been notified by the CM, it should make an enforcing decision. The enforcing can be done pro-actively, upon the actual behaviour of the parties (relationship 6a), or reactively, by incorporating the decision into the CV (relationship 6b) to prevent further access to the system by non-conforming parties.
We note that this analysis deals with explicit contracts: those that are applicable to situations in which there is some crossing of administrative boundaries and in which the trust among parties involved is such that contracts need to be established. These are governed by a set of rules emanating from a particular business law.
On the other hand, implicit contracts are the matter of parties to the contract themselves and are within the scope of an application domain. In this case only a relevant contractual component which provides a common understanding of contract element types needs to be involved. This for example may apply to a situation in which there is full trust between parties (as can be the case in network organisations) or when contracts are enforced by some indirect mechanism (e.g an authority mechanisms within a company's hierarchy).
In certain situations (referred to as neo-classical contracting [11]), it is beneficial to use a trusted third-party arbitrator which we call contract arbitrator (CA). CA has the role of evaluating the parties' performance, similarly to the CM, and also resolving disputes. This is an alternative to a costly litigation process.
This section demonstrates how each concept of our contract framework can be applied to the Internet with the aim of assisting in the promotion of electronic commerce.
A party to a contract is represented by a trading partner. This can include both the computer applications (e.g. EDI software at the sending or receiving side) and also individual users (e.g. buyers and sellers on the Internet).
While standardised EDI messages can facilitate interoperability between the trading partners, it is recognised that these are not sufficient for more complex business scenarios to be modelled [2]: those that require the incorporation of certain semantic aspects (e.g. of business contracts to provide support for a more rapid contract setting procedures).
In terms of the Internet, a business contract domain can be defined as a boundary within which the activities of trading partners are governed by the rules and policies of a particular business contract law. These rules are prescribed by the corresponding legislative authority(6) (e.g. of a state or a country). This includes the rules and policies within the domain as well as those which govern interactions between domains.
Initially, such a domain can be determined by a state, national or other regional boundaries. It can be expected that with an increased acceptance of electronic contracting, certain bodies, such as national and international standardisation organisations (or commercial companies such as credit card providers) could describe (or prescribe) rules that would comprise a specific domain of electronic interactions.
These rules and policies can be stored in the corresponding legal rules repository (LRR), which should be accessible by the CL component. This component could be implemented as a single object or a set of cooperating objects.
A contract domain can be realised in a variety of ways. Two examples are: i) a scenario in which the domain's LRR completely and solely controls a number of nodes and the networks between them or ii) a situation in which parties and contracts within the domain are distributed throughout the Internet where the authority of the jurisdiction over its members is retained.
It is worth noting that the paradigm of domains developed for management purposes in [12,13] can be adapted to further refine operations and relationships associated with business contract domains. In particular, there may be different relations between domains (e.g. hierarchical or peer-to-peer), which reflect relationships between different legal authorities and this can be included in a LRR. This will be investigated in future work.
Presently, the users of EDI use bilateral (or multilateral) paper contracts, which govern the rules of their relationship. These are referred to as `trading partner agreements' [14]. The establishment of such agreements involves substantial costs as they typically specify in detail business practices and technical requirements; effectively, the contracts semantics.
Few research attempts have been made to address this concern. For example, an approach which includes an AI technique and CASE tools, reported in [15], and an approach based on use of Petri Nets [6].
The concept of contract templates within our generic BCF can be used in the context of electronic commerce on the Internet, as an electronic representation of such agreements. Such a mechanism can be a suitable means to model business contracts since it can be used to:
We envisage that a repository, which can be made accessible via the Internet (according to particular permission rules), can be used to store:
There are presently many examples of repositories (both general and specific) available over the Internet, e.g. gopher, archie, veronica. A contract repository can be implemented as a separate repository or as a part of a repository which can store other types of information (e.g. based on type management systems, commonly used in open distributed systems [8]).
In addition to providing a storage function, such a repository should provide related management operations, to support the creation of the storage structure and the definition of relationships between contract types. For example, this should support addition of new contract types, specialisation of contract types from existing types and establishing other possible relationships between contract types.
A similar concept to contract templates can be seen in a use of document templates. For example, document templates accessible over the Internet, which contain a set of different types of standard paper formats (e.g. in PostScript, FrameMaker, Latex etc.) for this conference [16]. We anticipate that these will be defined by the emerging EDI standards, and in particular open-edi standard efforts [7]. Some of these templates can be further specialised to address the specifics of a particular business relationship.
The dashed line in Fig. 3 (between a party to the contract and contract repository) reflects the fact that trading partners will typically access this repository before being involved in contractual operations. This will be normally done when searching for a desired contract type.
Contract negotiation can be realised as the refinement of contract templates by the selection of contract subtypes and actualisation of contract element types.
This reflects the fact that negotiation often involves one party which submits a contract template offer, which the other party should either accept immediately or make a counter-offer. The subtype hierarchy can be used to determine the substitutability of contract templates. Substitutability can be used as the basis for acceptance of counter-offers.
Contract validation is an optional step performed individually or collectively by trading partners which are creating the contract. As described in 3.4, there are four elements of a legally valid contract. The realisation of these elements in the Internet environment occurs as follows:
To summarise, contract validation can be realised by using rules and policies of the underlying business contract domain (possibly incorporated in the contract repository) and through implementation of appropriate supporting services to facilitate validity checking.
After the contract element types are checked for validity and the contract is accepted by all trading partners the interactions governed by the contract can proceed. In the course of this, either trading partner may check whether the contractual obligations have been met during the contract realisation, i.e. the consideration element of the contract is being fulfilled. More specifically, this requires recording of the actions and measurement of the performance of parties, ensuring that they comply with the contract specification.
Contract monitoring can be done by parties themselves and possibly verified later by contract enforcement activity if needed; similar to maintaining diaries which can be regarded as some sort of legal documents.
Alternatively, a trusted third-party contract monitor (CM) can be used by one or more parties to the contract. The parties employing the CM specify the actions required upon detection of contract non-performance, e.g. it can notify an appropriate contract enforcement component.
Hence, the CM has the following roles:
Contract monitoring can be implemented either within the software of individual trading partners or by the auxiliary components which will monitor the interactions between the representative objects.
There are presently various mechanisms within the Internet which can be used to perform some monitoring functions. For example, news and e-mail services provide means for monitoring both the transmission path and status of messages. These can be extended with specific requirements related to electronic commerce. Additionally, some quality of service characteristics (e.g. transmission time of e-mail messages) can be monitored.
Contract enforcement should ensure that the actual behaviour conforms to the contract. This can be done in either of the following ways.
We note that the pro-active approach to contract enforcement is not widely used in business contracts. We envisage, however that a system of electronic commerce can effectively support pro-active enforcement, since a business law is normally less ambiguous than common law and direct interpretation is possible. Additionally, reactive and post-contract enforcement will usually require arbitration and possibly human intervention in determining the appropriate (corrective or punitive) actions.
Several mechanisms are currently available on the Internet which can support contract enforcing. For example, it is possible (by a controlling node on the message path) to restrict transmission of news and e-mail messages to or from certain parties. This can be adapted to the specifics of the contract enforcement in the context of electronic commerce on the Internet.
In this paper we identified a number of problems which currently represent an obstacle for the wider use of electronic commerce mechanisms over the Internet, in particular for inter-organisational business dealings. While there are a variety of technological problems currently being addressed in the research community (e.g. those related to security, availability and reliability issues), we have highlighted additional problems. These arise from the current lack of a suitable semantic representation of typical business scenarios and the absence of a legally valid framework for the support of electronic commerce on the Internet.
This paper can be regarded as an initial attempt to address these issues: we focused on one important class of business operations associated with establishing contracts and monitoring and enforcing behaviour governed by these contracts. The generic framework previously developed has been used to provide an initial framework for the support of inter-organisational business dealings over the Internet. We believe that this work, along with other contributions, especially [17], can provide an increased confidence in using electronic commerce features. However, we also note the complexity of these issues, which makes it hard to expect that all interactions can be automated. A number of activities will still require human intervention, e.g. interpretation of law and subjective judgements such as "intent", "negligence" and the ultimate authority of society's legal system.
The work reported in this paper has been funded in part by the Cooperative Research Centres Program through the department of the Prime Minister and Cabinet of the Commonwealth Government of Australia.
Zoran Milosevic is a PhD student at Computer Science Department, The University of Queensland, Brisbane, Q4072, Australia. He is currently at a final stage of his study, which deals with economic and business aspects of open distributed systems. This includes investigation of how these disciplines can help IT strategists and managers to design systems which would best meet the objectives of their enterprises. The particular focus is in the economic role of Quality of Service in such systems and how this can be incorporated in supporting IT architectures. Zoran has previously worked as a software engineer and system designer for real time systems. He has also had a number of consulting roles. He holds BSEE (Hons.) and master degree in computer science from the University of Belgrade, Yugoslavia.
Andy Bond is a Senior Research Scientist at the Distributed Systems Technology Centre, DSTC (Level 7, Gehrmann Laboratories, The University of Queensland, 4072, Australia) and heads the Distributed Environment Project within the Architecture Unit. His main focus is the provision of essential services within an open distributed environment. This includes support for distributed objects within a open distributed framework. Andy came to the DSTC after completing his PhD at Victoria University of Wellington. His thesis work covered the allocation of tasks in distributed systems with emphasis on task resource prediction.