Electronic commerce is the ability to perform transactions involving the exchange of goods or services between two or more parties using electronic tools and techniques. It offers many advantages over traditional paper-based commerce:
A convergence of several factors has recently lifted electronic commerce to a new level of utility and viability. These factors include the increased availability of communications and communications bandwidth, the reduced cost and increased user-friendliness of computers and communications, the growth of the Internet and online services, and the drive toward global competitiveness.
Currently, online purchases account for only 4 percent of total global purchases; online purchases via such precursors as the Internet are practically nonexistent. But electronic commerce is likely to grow dramatically over this decade. For example, it is predicted that within 6 years, global shoppers will use the national information infrastructure (NII) to purchase $500 billion of goods and services; this represents almost 8 percent of current purchases worldwide. And by 2005, the number of NII-based transactions is expected to rise to 17 billion, which is almost half the number of transactions made in today's credit card market.
In recent years, great strides have been made to automate many of the labor-intensive paper-based aspects of commerce. Examples abound of corporations that use electronic data exchange (EDI), electronic mail (e-mail), electronic forms (e.g., for ordering or for contracting), and electronic catalogs, and of electronic financial networks that speed the transfer, settlement, and clearing of funds and other financial instruments. These electronic tools and techniques provide many benefits to both customers and merchants. EDI standards, for example, enable fast, accurate information exchange between different automated systems in routine, relatively simple business transactions.
Unfortunately, despite the widespread use of numerous methods of electronic support, electronic commerce is still not the most common method of carrying out business transactions. This is so for several reasons. For one thing, most business transactions still require the physical exchange of paper documents and instruments, with the inherent costs and delays this represents. For another, current electronic commerce approaches are not sufficiently well integrated, secure, open, or easy to use:
Many new systems and service initiatives have been announced for the Internet and the evolving NII that address one or more of these current deficiencies to varying degrees. These include initiatives such as (1) CommerceNet and Secure Hypertext Transport Protocol (SHTTP), (2) electronic catalogs, (3) advanced search engines, (4) e-mail-enabled EDI, and (5) digital cash. Additionally, several alliances and partnerships have been announced that address the need for secure, affordable payment, linked in real time to ordering and billing systems. These initiatives include ventures by Open Market, Microsoft/Visa, Netscape/First Data/MasterCard/Bank of America, Cybercash/Wells Fargo, American Express/America Online, First Virtual/EDS, NetBill, NetCash, Cafe-Digicash, Mondex, NetCheque, NetAccount, Netchex, AT&T, and InternetMCI. More such alliances and start-ups are announced each day. These initiatives promise to accelerate the future growth of electronic commerce and rapidly decrease the overhead and time associated with today's paper- and people-intensive activities.
So, in the near future, we should see a broad range of new value-added electronic commerce services, including the following built around trust and security:
All of these initiatives must be developed within a common framework, or we run the risk of creating isolated, noninteroperable implementations that will inhibit progress toward truly free, open, and spontaneous electronic commerce. The joint ventures listed here, for instance, all vary in their approach to security and privacy, their ability to handle micropayments, and their applicability to various types of transactions. They also differ in their business models—for example, in their pricing strategy and in their assumptions as to who bears the risk in case of insufficient funds or disputes.
The electronic commerce infrastructure must therefore do the following:
Some related issues important to the design of an electronic commerce framework are discussed below:
As new initiatives start up under a common framework and set of standards, performed over low-cost commodity computers linked by open public networks, competitive pressures and technology advances should drive down associated costs and time and increase interoperability and competitiveness. New forms of commerce will arise that were impractical under the old cost structure, and the virtual enterprise will be fully realized. Consider the following examples of what life might be like in the future NII if this electronic commerce infrastructure is realized.
Mary wants to lease some warehouse space in a distant city that she will use as a distribution hub. Her main concerns are location, price, and early occupancy. She clicks an icon displayed on her PC that establishes an online connection to several broker icons advertised on the World Wide Web (WWW). She clicks on each of these broker icons in turn to scan their home pages. Soon, she finds a property for lease that seems to match what she is looking for. The property is at the intersection of two major highways, has sufficient square footage, is being offered for a reasonable monthly price, and is available for lease at the beginning of the next month.
Mary checks the broker's credentials by clicking on a certification icon. The broker's credentials are immediately transmitted to a reference service for authentication. Within seconds, the reference service sends Mary an e-mail message with the certification attached; Mary is alerted to the arrival of this message by a special interrupt tone on her workstation.
Mary then clicks on the appropriate button, and an electronic application form to lease the property appears. She begins to fill out this form and inserts her electronic bank card into the PCMCIA slot in her PC, which digitally signs the application with her financial credentials and binds the application data to her signature so that it cannot be altered. Mary then clicks the send button to transmit the application to the broker. The application contains her identification, billing address, and permission for the broker to obtain a credit reference from her bank. Mary then closes the broker page and turns to another task.
Several minutes later, the broker has completed a review of Mary's application, including obtaining and analyzing her bank's credit reference. Most of this work was performed by intelligent software agents that were automatically activated and tasked upon receipt of Mary's electronic application form. Since Mary's background check was routine and acceptable, the application's approval was automatic. Accordingly, the broker can send Mary a standard rental contract. She receives this as an e-mail attachment concurrent with notification of acceptance of her application.
Mary inspects the contract and finds its terms generally acceptable, except for two items:
Mary e-mails these exception items to the broker, who reads and approves the changes, and makes one additional change: He specifies the conditions under which Mary is justified in stopping payment. This information is communicated via e-mail to Mary, who finds the conditions acceptable and date/time-stamps them, and again digitally signs the digital contractual agreement. She sends it back to the broker, who in turn digitally co-signs it. The process is witnessed by a network notary, who digitally signs the contract as witness; holds the original digital copies; and sends authenticated copies to Mary, the broker, their respective banks, and the appropriate government agency for filing and recording.
Now, each month Mary's bank notifies her by e-mail that it will electronically transfer funds from her account to the broker's account unless it receives override instructions from her within 24 hours. Mary completes the required acknowledgment of these electronic notices and date/time-stamps them. When the bank electronically withdraws funds from her account to meet the lease agreement, this information is automatically transmitted to the broker via e-mail. The broker's financial software agent automatically makes the electronic deposit of the funds. Intelligent agents for the bank and broker then automatically update all appropriate financial records.
Dave gets an e-mail inviting him to a formal black-tie dinner tomorrow when he returns from his business trip. Unfortunately, he does not own a tuxedo and is 3,000 miles from his home. In the past, he has ordered a rental tuxedo from a neighborhood store via computer. Since his last promotion, however, he has been getting invited regularly to formal affairs and can easily justify buying rather than renting a tux. He dials up his electronic yellow pages, searches for tuxedo manufacturers, explores their interactive multimedia advertisements, and finally finds a supplier to his liking. It allows him to customize his own tuxedo design online and promises 24-hour delivery to any location in the United States.
Dave requests linkage to the tuxedo manufacturer's interactive design facility. A range of charges that vary according to the quality of transmission (image resolution and response time) is displayed, and Dave is prompted to make a selection and to insert his American AAdvantage Citibank Visa smart card into his PC reader. Dave makes a selection and inserts the card, which issues a payment transfer from his credit card account to the electronic yellow pages, subject to Dave's approval and authorization. Dave approves the charge, digitally signs the authorization sealed with his unique personally encrypted retinal scan recorded by a camera mounted in his portable PC, and inserts his card, thereby transferring the payment. Dave is connected to the tuxedo manufacturer design service.
The tuxedo manufacturer requests that Dave transfer his dimensions. Dave does so easily, his dimensions being stored on a file in his PC. The manufacturer then transmits a number of images of typical tuxedo designs for Dave's selection. Dave enlarges a few of these images to full size, adjusted to his form and dimensions. He rotates them and views them in three-dimensional projection from many viewpoints, and selects one. He then proceeds to manipulate this design using his electronic pen; he makes minor adjustments and changes to the tuxedo, raising the waist and tapering the pants legs to better match his personal taste. He next specifies the material: 100 percent wool, treated for stain-proofing and wrinkle-proofing. When it is finished, Dave transmits the revised design to the manufacturer, along with the desired delivery date and location. The manufacturer replies with a charge appended to the design; this specifies the delivery date and location, and the terms and conditions of payment (either a credit card charge now, or a 20-percent-down cash transfer now with the remainder due in cash on delivery). Dave digitally signs the electronic agreement with his American AAdvantage Citibank Visa smart card, which he uses as payment, and sends it back to the manufacturer.
The manufacturer receives the order and payment, and issues the design specifications along with a unique order number to its factory for manufacture. At the same time, the manufacturer sends an order to Federal Express for pickup and delivery of the completed suit that afternoon; this order includes the suit's unique order number, delivery address, customer name, and identifying encrypted retinal scan. By 3:00 p.m., the completed tuxedo has been picked up by the messenger.
At 8:00 the next morning, Dave arrives at his office. Within 2 hours, a Federal Express messenger arrives at his office with the suit. Dave authenticates himself, matches his retinal scan, and receives the tuxedo in plenty of time for the evening's formal dinner.
To achieve the vision outlined above for electronic commerce, we need a comprehensive architectural framework and a set of base infrastructure services and standards around which these and future initiatives can be designed. The architecture must permit the flexibility, interoperability, and openness needed for the successful evolution of electronic commerce over the NII. This framework, and its services and products, will offer the consumer a diverse set of interoperable choices, rather than a collection of independent "stovepipe" solutions.
This framework should set the groundwork for developing the electronic commerce infrastructure. To this end, we begin by discussing the basic activities and functions associated with electronic commerce, identifying the key building blocks required to support those functions and activities, and describing key infrastructure services and application programming interfaces (APIs). These services and APIs are placed within an electronic commerce application architectural framework consisting of a services infrastructure layer and an applications layer that interface with each other and with the physical layer. These layers are defined in terms of APIs and objects from which the various electronic commerce applications can be constructed.
There are nine key activities in commerce:
The specific functions associated with these activities in an electronic commerce setting are discussed below. Note that not all of these activities are performed in every transaction, nor are they necessarily performed in this order; indeed, they may be performed in parallel. Also, the activities are not necessarily all conducted electronically. Finally, these activities can vary in complexity and importance depending on the size and scope of the transaction.
Advertising and shopping can include the following:
A major problem associated with the advertising and shopping activity is the cost and time expended in developing, maintaining, and finding relevant information, products, and services, given the plenitude of available information. Obviously, this problem will become increasingly complex as more data and services become available online and the choices and possibilities multiply exponentially. We need new and better ways to find services and information and to publish and update this information.
Buyers and sellers may elect to negotiate the terms of a transaction (i.e., the terms of exchange and payment). These terms may cover delivery, refund policies, arranging for credit, installment payments, copyright or license agreements, usage rights, distribution rights, and so on. These terms can be standardized for routine commodity use, or customized to suit unique individual situations. Often, in the case of two parties with a well-established business relationship, the terms of exchange are prenegotiated as standing contractual terms for all their future exchanges. Often, this process will also include authentication of the two parties.
The buyer eventually issues a contractual agreement of the terms of exchange and payment. This contractual agreement is generally issued as an order, which sets forth the quantity, price, and other terms of the transaction. The order may be verbal, in writing, or electronic. It usually includes an acknowledgment of agreement by the various parties in order to help prevent any future repudiation. This agreement can be confirmed electronically through cryptographic techniques such as digital signatures.
In the case of some commodity purchases, the entire transaction may begin at this ordering stage, bypassing the advertising/shopping and negotiating activities. The ordering activity applies to all transactions, regardless of whether billing will be involved. For example, even requests for free public information should be issued as formal orders so that the service provider can record and account for information requests.
Once a seller has delivered goods or services, a bill is sent to the buyer. This bill generally includes remittance information that should accompany the payment. Sometimes, a seller may require payment in advance. Sometimes, a supplier sends advance shipping notification, and the customer agrees to authorize payment upon confirmation of the arrival of the products. And in some cases, as with the free information example cited above, this activity is eliminated entirely.
The buyer, or some financial intermediary, eventually sends some form of electronic payment (this could be some form of contract or obligation, such as authenticated payment instructions or digital cash), usually along with some remittance information to the seller. This payment may occur for a single item, on a usage basis, or with a single payment for multiple items or usage. Settlement occurs when the payment and remittance information are analyzed by the seller or the seller's agent and accepted as valid.
Either before, after, or concurrent with payment, the seller arranges for delivery of the purchased goods or services to the buyer, and the buyer provides the seller with proof of receipt. Policies regarding customer satisfaction and return should be negotiated prior to this activity and made part of the contract between buyer and seller. For larger, more complex orders, distribution may involve more than two parties and entail complicated distribution coordination strategies. An ancillary distribution service involves acting as a fiduciary, and holding goods, certificates, bonds, stocks, and the like in trust.
This activity is particularly important to corporate customers and suppliers. Both buyer and seller must reconcile all electronic transactions in the accounts receivable and accounts payable, inventory information, and accounting systems. Account and management information system records must also be updated. This activity can involve third parties, if the transacting businesses outsource their accounting services.
Customer service entails the following:
Customer service also involves providing general cash management advice, including addressing foreign exchange imbalances and risk exposures, collection of delinquent payments and late fees, and repossessing products for which payment is long overdue.
A final key activity in electronic commerce is the collection, management, analysis, and interpretation of the various data to make more intelligent and effective transaction-related decisions. Examples include collecting business references, coordinating and managing marketing strategies, determining new product offerings, granting and extending credit, and managing market risk. Performance of these tasks often involves the use of advanced information management techniques, including models and simulations and collaborative computing technologies to support conferencing and distributed workflow processes.
These tasks will become more difficult as the sources of information grow in number and are of increasingly diverse and uncertain quality. Additionally, procurement of this information may raise significant privacy concerns and issues.
A MODEL FOR ELECTRONIC COMMERCE
To support the electronic commerce activities and functions discussed here, and to accelerate the electronic commerce vision described earlier, we need an open electronic commerce architecture and a set of agreed-upon electronic commerce infrastructure standards and services. These elements are detailed in the following sections; here we describe an overall model of electronic commerce.
Major electronic commerce applications can be built by interfacing and integrating, through APIs, elemental electronic commerce building blocks and services; these latter are provided by a variety of service providers and application designers. The enabling infrastructure services include those needed to provide requisite transaction integrity, authentication, and privacy. The enabling services and APIs must be at a low enough level of detail (granularity) to provide open, seamless links to the key electronic commerce building blocks and services; they also must be simple and flexible enough to permit user customization and continuous improvement and evolution over time. To maximize flexibility and modularity while admitting alternative competing implementations, an object model is preferred for describing and invoking these building blocks.
The object model has close parallels with the digital object model associated with the Defense Advanced Research Projects Agency (DARPA) Digital Library Program. Both object models share many of the same needs and attributes (i.e., the need for naming, updating, retrieving, routing, pricing, and maintaining a repository of digital objects, and for addressing copyright and usage concerns). Three key questions remain:
1. Should the application objects and services be self-describing?
2. How should they be standardized, named, accessed, and updated (i.e., should we adopt object request broker standards)?
3. How can they best be interfaced and integrated into existing processes, procedures, and legacy systems?
We envision a three-layered electronic commerce architecture, in keeping with that described in a previous Cross-Industry Working Team (XIWT) paper, with an architecture consisting of the following:
This architecture includes the infrastructure services needed to support the major electronic commerce activities discussed here and the key electronic commerce services, objects, and APIs discussed below.
Several generic infrastructure services are critical to a successful electronic commerce framework:
All of these services will probably be needed for most other applications domains as well and have been or will be discussed in other XIWT papers in this regard. In this section, we discuss these elements with particular reference to their application in an electronic commerce setting. We also discuss specific services unique to electronic commerce (e.g., paying and accounting).
For electronic commerce, existing communications mechanisms (e.g., virtual circuits, routing and addressing, datagrams, e-mail, file transfer protocol [FTP], HTTP, with image and other multimedia extensions) must be extended to incorporate the following features:
These extensions are either generally available or under development. However, to support electronic commerce, they must work across a variety of information and communications devices (including telephones, personal computers and workstations, set-top boxes, and personal information managers and communicators); human-machine interfaces (ranging from character text to virtual reality, and from keyboard and electronic pen to speech recognition and gestures); communications media (including satellites, cable, twisted wire pair, fiber optics, and wireless, which includes constraints on available communications bandwidth and reliability); and nomadicity (which includes supporting location independence, and remote personal file storage with privacy encryption).
Security is a critical component of any electronic commerce application and must be addressed in designing any electronic commerce service infrastructure. Electronic commerce system security should provide the following types of guarantees to the user:
Once authenticated, users need to be authorized for requested services and information. User authorizations can be provided as a blanket binary approval or granted only under or for specified conditions, time intervals, and/or prices. Authorizations can be provided to designated individuals or to designated organizational representatives. It is therefore often desirable to authorize a user in terms of his or her location and organizational function/role, as well as on the basis of individual identity.
Translators can transform and interpret information from one system into formats more suitable to other interacting objects and systems. Translator services should be able to adapt and evolve automatically. For example, a translator that can interpret a small subset of electronic forms that have been linked to SQL relations and data dictionaries should be able to prompt the user for any needed additional information and update itself accordingly. The translator could then be incrementally expanded by further manual linking of data relations to electronic forms, by direct user query, and by learning from example. This capability for selective incremental expansion would enable a user to customize translators to meet unique needs and to expand the translator easily so as to handle larger vocabularies and collections of electronic forms/documents as needed, as well as incorporate new EDI standards as they evolve and become defined. Finally, such a capability would help simplify and speed up the EDI standards process.
Software agents are intelligent programs that simplify the processing, monitoring, and control of electronic transactions by automating many of the more routine user activities. Software agents may be local programs running on the user's machine, or they may actually transport themselves over the network infrastructure and execute on the service provider's machine.
Agents are a relatively new development. Currently, they can do such things as filter incoming mail, coordinate calendars, and find desired information for presentation to the user. Over the longer term, agents are likely to take over more complex tasks such as negotiating, translating, and overseeing and auditing electronic transactions. Some additional future uses for software agents include personalization and customization of applications, and personalized searching, filtering, and indexing.
Eventually, we may have many different agents working for us, coordinating and communicating among themselves. When this comes to pass, we will need standards and infrastructure to support the necessary management, negotiation, and coordination not only between users and agents but also among agents, and to maintain agent repositories where agents can be stored, retrieved, purchased, and leased.
In an electronic commerce setting, software agents should be able to do the following:
Generic Services. Distributed information resource discovery and retrieval services help service providers list and publish their services, and help users find services and information of interest. These information services cover the ability to maintain, update, and access distributed directory services. They also cover more advanced navigation services such as maintaining hyperlinks, advanced keyword and context search engines, and software agents, such as Web crawlers, that can explore and index information sources and services of interest. These services should be easy and efficient to update as well as to access and use. They should also be capable of being implemented, maintained, and accessed over a number of locations distributed across the NII.
Unique Services. In addition to the generic services just discussed, there are a number of desirable infrastructural services that are unique to electronic commerce:
In addition to the services cited above, the activities and functions of electronic commerce require certain basic building blocks:
Over time, these items will probably become increasingly comprehensive and refined.
These building blocks can be best described as classes of digital objects. A digital object is an ordered sequence of bits associated with a handle, or unique identification, that can represent a collection of operations (behaviors) and information structures (attributes); and where an object class represents a collection of objects that share a common set of attributes and behaviors. A digital object can be composed of one or more of these classes; for example, an e-mail object has both structured and unstructured information. Digital objects are particularly useful because they are associated with real objects (e.g., a contract making them easy to understand) and because they can be specified and accessed in an application-independent manner, making them easy to create, reuse, enhance, modify, and replace, and to interface with existing objects, with minimal side effects.
Electronic commerce activities can be specified in terms of the interactions between real objects (e.g., transacting parties) and digital objects (e.g., electronic documents, software agents). An electronic commerce architecture can be defined in terms of how these object classes are defined (e.g., their attributes and behaviors) and how the objects interact with one another. An electronic commerce transaction can also be implemented as an interacting network of these objects, where each object can be dynamically selected as a function of the specific situation.
Electronic commerce digital objects have several important properties that are discussed below.
Several operations and controls can be associated with any electronic commerce digital object.
Usage tools and controls. Examples of usage control include allowing the digital object to be created; published; displayed or read; written to and updated; and reproduced and copied (note, however, that for some object classes, it may be desirable to inhibit copying), subject to various restrictions and charges. These controls can restrict use to particular authorized users and with selective access criteria specifying type of use (e.g., read only). Usage controls also include such operations as enforcing intellectual property usage rights and charges, version-control and backup, change control, and group sharing (e.g., collaborative authoring). Objects should be able to be compressed, decompressed, and manipulated in ways appropriate to their format (e.g., images can be rotated, enhanced, have features extracted and/or matched, enlarged and reduced in size; or video and sound can be skimmed and/or played in fast time or slow motion).
Several key digital objects for electronic commerce are listed below.
Examples of contracts include the following:
Contracts can include instructions regarding the handling, routing, storing, scheduling, and workflow of the contract itself and of other objects contained in or referenced by the contract. These instructions can address liabilities; acceptable forms of payment (cash, credit card, debit, or check); terms of payment (usage charges, periodic and one-time charges); billing and payment instructions (credit to merchant, automatic debit card deductions, billing and payment addresses, due date); delivery instructions (where and how to deliver); return policies; methods of error and dispute resolution; and conditions of good delivery. Contracts can be negotiated, including prices, terms of payment, penalties, necessary documentation, credit checks or required insurance, and collateral or margin. They can be written, signed, read, and amended. In many instances, contracts can also be bought, sold, and exchanged. In many cases (for example, in the case of electronic cash), contracts should not be able to be altered, reproduced, or copied.
Examples of information documents include the following:
Information documents can be unstructured, partially structured, or completely structured. They can be browsed or searched, and bought, sold, exchanged, and copied, under contractual constraints. They also can be created, updated, signed, copyrighted, and read, then synchronized, morphed, compressed, and decompressed.
Accounts include the following information:
Accounts can be opened, closed, linked, updated, blocked, stopped, or attached. They can receive deposits, debit withdrawals, and accept transfers. Also, accounts and account information such as account balances can be verified. Since linked transactions (for example, billing, paying, receipt, and delivery transactions) are not generally simultaneous or one to one, it is often necessary to reconcile account information. The ability to link and associate account and remittance objects to payment transactions helps simplify account reconciliation. Account operations are accomplished through transactions, which are discussed later in this section. It is generally necessary to establish audit trails, so that the consequences of multiple transactions on an account can be tracked.
Software agents include the following:
An agent should be able to serve in more than one of these roles.
Both physical objects (e.g., cars and clothing) and digital objects (e.g., program logic, digital movies, data, electronic design specifications, electronic contracts) can be sold and exchanged.
Transactions are generally governed by contracts and update accounts. They can operate on all the other digital objects and generally involve the transmission and exchange of two or more digital objects (e.g., a movie for money, medical services for money, exchange of two currencies, etc.). They can also include the exchange of bills and invoices and of information and services.
Transactions can be designed to be anonymous and untraceable or traceable and auditable. If they are designed to be untraceable, they lose many of their information features. A more satisfying compromise is to execute a transaction that can only be traced with the consent, approval, and active cooperation of the user.
Transactions can, but do not necessarily always, include the following information:
Transactions can be reversed, repaired, disputed, monitored, logged/recorded, audited, and/or reconciled and linked (e.g., matched and associated) with other transactions. If the transacting parties want to make the transaction anonymous or untraceable, then the users will forego many of the above features. A compromise is a transaction that can only be traced with the consent, approval, and active cooperation of the user or designated escrow agents.
APIs and information exchange protocols are needed for digital object operations and infrastructure services. Many APIs—for example, FTP, HTTP, simple mail transport protocol (SMTP), and multimedia information exchange (MIME)—already exist and could be considered as a starting point for the NII. Additional APIs specifically needed as interfaces between electronic commerce objects and infrastructure services include the following: