A Web-based and Email Driven Electronic Contract Management System

Thomas Kwok, Thao Nguyen, Linh Lam and Trieu Chieu

IBM Research Division Thomas J. Watson Research Center

19 Skyline Drive, Hawthorne, NY 10532 kwok@us.ibm.com

Abstract

In an enterprise, managing and processing an electronic contract often involves a number of contract administrators and representatives in the enterprise, and their counter parts in their suppliers, business partners or their customers to carry out a large number of complex manual tasks in sequences during the life cycle of electronic contract. In most commercially available electronic contract management systems, users either waste a lot of their time in monitoring their task lists for their turns to act on their electronic contracts or most electronic contracts simply stay idle for most of the time if users only check their task lists once a while. In addition, these manual tasks are often tedious and may cause security faults.

In this paper, we present a Web-based and email driven electronic contract management system that supports both internal and intra-enterprises workflows, and with multi-tenants hosting capability. This system enables a user to act on the next task in a sequence of tasks to process a particular electronic contract immediately after the other user has completed the previous task in the same sequence of tasks by sending out email notifications to alert or remind the user to take action on the task. We also describe several novel methods to automate some manual and tedious tasks, such as watermarking signature information on the signed electronic contract and life cycle management, in this paper. Most users have found their productivities improved, the electronic contract transaction time accelerated, contractual errors reduced and many other benefits by using this electronic contract management system in several IBM pilot programs.

1. Introduction

Contracts are required in most transactions of the enterprise business, as they constitute the binding relationship between an enterprise and its suppliers, business partners, or customers. In many enterprises, the majority of their revenues are contract driven. At the same, a significant part of their expenses is also contract

related. Automation of some contract management tasks in the electronic contract lifecycle presents a substantial value creation opportunity for the enterprise. This value stems from improved productivity and security, effectively aggregated contract information, accelerated contract transaction time and lifecycle processes, reduced contractual errors and risk, enabled revenue forecast and profit optimization, as well as better compliance enforcement [1].

With the advent of Internet technology and electronic commerce, there are growing research activities and implementation efforts on establishing and standardizing an electronic contract management system. Currently, the International Association of Contract and Commercial Managers have listed over twenty commercial available software products for electronic contract management [2]. Most research activities on the electronic contract reported are focus on electronic contract creation or representation language [3], management [4], negotiation and collaboration [5], execution [6], performance [7], security and signing [8], fulfillment [9] and data mining [10]. However, there is no study or product focus on a Web-based electronic contract management system that can support both internal and intra-enterprises workflows, or with multi-tenants hosting capability. There are some discussions [6, 7] in addressing the need to execute electronic contracts in a speedy way but there is no good method proposed. In addition, there is no good disclosed method to automate the watermarking of signature information on the signed electronic contracts although there are several automated electronic contract creation and process methods reported [3, 4].

In this paper, we present a Web-based and email driven electronic contract management system that supports both internal and intra-enterprises workflows, and with multi-tenants hosting capability. This system sends out email notifications to request those users who are required to act on certain tasks to process their electronic contracts to act on their tasks immediately at every internal business process and document flow step within every workflow. For sequential tasks, this system also sends out email notifications to those users in line to act on the next task to process their electronic contracts to

IEEE International Conference on e-Business Engineering

0-7695-3003-6/07 $25.00 © 2007 IEEEDOI 10.1109/ICEBE.2007.23

149

IEEE International Conference on e-Business Engineering

0-7695-3003-6/07 $25.00 © 2007 IEEEDOI 10.1109/ICEBE.2007.23

149

IEEE International Conference on e-Business Engineering

0-7695-3003-6/07 $25.00 © 2007 IEEEDOI 10.1109/ICEBE.2007.23

149

alert and remind them to take actions when other users have just completed the previous tasks. Thus, this system enables the electronic contract users to accelerate the transaction time and life cycle of their electronic contracts. We also describe several novel methods to automate some manual and tedious tasks, such as watermarking signature information on the signed electronic contract and life cycle management, in this paper.

2. The framework

Figure 1 shows an architectural framework of an email

driven electronic contract management system. This electronic contract management system is Web-based and supports both internal and intra-enterprises workflows. It also has a capability of hosting multi-tenants at the same time using the same set of computing servers. The framework consists of a Web server, a DB2 server and an application server. The Web server dynamically creates, composes and delivers customized Web pages with inputs and interactions from contract administrators and representatives in an enterprise, as well as their counter parts in their suppliers, business partners, and their customers through either HTTP or HTTPS communications. The DB2 server hosts the database for the electronic contract metadata and the repository for all electronic contracts and their related documents. Each enterprise or tenant has its own set of database. A service provider, such as IBM, can use or host this electronic contract management system as common computing services to a number of enterprises to manage their electronic contracts at the same time using the same set of computing servers to minimize the cost and simplify the system integrations.

The application server hosts the main core engine of

the electronic contract management system. The main core engine comprises eight important modules, an

administration module and an access control module, a workflow module, an email notification module, an electronic signature module, a document management module, a data extraction and search module, and a lifecycle management module. The administration module is used by the contract administrators of each enterprise or tenant to setup, configure and customize all system and contract related parameters as this electronic contract management system supports multi-tenants or many enterprises at the same time. The access control module authenticates authorized users to access or enter the electronic contract management system as well as to perform and execute certain electronic contract management tasks. The workflow engine and its configuration tool in the workflow module supports both internal and intra-enterprises workflows. The email notification module creates and stores the metadata of those ready to send emails. It has a service daemon to compose the content of the ready to send email as well as send it out every 3 to 15 minutes. It also allows authorized users to track, retrieve and resend old emails. The SMTP server acts as an email server to propagate emails to the contract administrators and representatives in an enterprise, their suppliers, business partners and customers from this electronic contract management system. The electronic signature module records and stores electronic contract signing information. It also composes an electronic contract signature file in a viewable form, such as a PDF file format. Then, it superimposes a watermark of contract signing information on the signed electronic contract document. The document management module uploads, downloads, stores and retrieves all electronic contracts and their related documents. The data extraction and search module extracts metadata from the electronic contract document. It also provides a metadata and keyword search capabilities for users to retrieve their electronic contracts and related documents in the database and repository. The life cycle management module is also a service daemon. It performs a set of pre-defined automated electronic contract management tasks, such as activate signed contracts, cleanup all workflow steps of rejected contracts and delete already expired contracts beyond retention periods.

All communications, interactions and connections among contract administrators and representatives of enterprises, their suppliers, business partners and customers, the Web server, the application server and the remote or local databases go through one or more secure wired or wireless networks. As a result, this Web-based electronic contract management system enables authorized users to carry out different contract document tasks, as well as sign electronic contracts in real-time using a Web browser without additional hardware and software installation. Many contract representatives, each

150150150

assigned to perform the same or different contract tasks on the same or different types of contracts with different workflow steps, can simultaneously access this electronic contract system using a Web browser. 3. An administration module and access control

The contract administrators of each enterprise use the administration module to setup, configure and customize all system and electronic contract related parameters. The administration module provides a set of graphical user interfaces (GUIs) for contract administrators in an enterprise to customize email message contents for different types of email messages send to contract users, as well as the warning and retention periods for soon to be expired and expired electronic contracts beyond retention period respectively, for their enterprise. The contract administrators also use the GUIs to assign users certain contract management tasks, as well as to configure the workflow of different types of electronic contracts used in the enterprise. The contract administrator also configures an access control list for each flow step of a workflow in each type of electronic contracts. This access control list authorizes a group of users from an enterprise to perform certain contract management tasks on a specific type of electronic contract at a specific flow step in the workflow. There are also different roles assigned to different users to support the administrative related tasks of the electronic contract management. Examples of these roles are approver, reviewer, signer, counter signer and so on. The administrator can assign one or more of these roles to an individual user or a group of users. Each role entitles them to perform certain tasks on the electronic contracts routed to them.

In addition to the access control governed by roles, the contract administrators can assign different access levels to different users to limit their accesses to the electronic contracts within their enterprise. For example, users can access any electronic contracts within their enterprise with assigned access level one. However, users are limited to access those electronic contracts belonging to their own departments within their enterprise with assigned access level two. With access level three, users can only access to those electronic contracts submitted by them. The access control list can be reconfigured anytime to support delegation to cover users unavailability or in case of unexpected situations when a user cannot carry out their responsibilities. Further, the contract administrators can reconfigure the access control list to designate a specific user (by restricting the rest of the other users) to handle certain electronic contracts because of their particular nature i.e. the contract amount exceeds certain dollar limit.

4. Internal and Intra-enterprises workflows

The Web-based and email driven electronic contract management system provides a workflow configuration tool with a set of workflow templates for the contract administrators in an enterprise to configure different internal workflows to process each type of electronic contracts in their enterprise. A workflow template describes a sequence of process steps on how an electronic contract flows through from its creation to completion during its life cycle. There are two types of internal workflows, an electronic contract document flow and an internal business process flow. The configuration tool first guides the contract administrator through a sequence of steps to create and configure the necessary process steps for a new electronic contract document flow. The steps involved are:

• Augmenting information of the contract document flow – flow name, ID and description

• Adding process steps to the contract document flow – a flow must have a starting and an ending steps with one or more intermediate steps in between

• Configuring the contract document flow – routing the created process steps together to make a meaningful document flow and deciding on a list of actions supported in that process step

Then the workflow configuration tool again guides the

contract administrator through another sequence of steps to create and configure the required internal business process flow steps associated with a particular document flow step. It does that by allowing the insertion of several flow steps of an internal business process flow to this particular document flow step. Figure 2 is a flow chart illustrating the execution of an electronic contract document flow consists of a number of document flow steps. Each document flow step may also comprise

151151151

several flow steps of an internal business process flow. As shown in Figure 2, an internal business process flow is similar in structure as a contract document flow. An internal business process flow can only be launched when the logic of the electronic contract execution control reaches a document flow step that it is associated. It cannot be invoked directly from the outside the document flow. An example of such a flow step of an internal business process flow is that an enterprise may require its electronic contracts to go through multi-levels approval before they can be forwarded to obtain their final approval signature. To support this scenario, the approval step in the document flow will include these internal business process steps, namely the multi-levels approval processes, of the enterprise. When an electronic contract arrives at the approval step of the document flow, it will be routed to the multi-level approval processes of the enterprise as an internal business process flow.

When an electronic contract is submitted, it kicks off a thread to run an instance of a document flow that this electronic contract life cycle is going to utilize. The execution of the instance begins at the starting document flow step of the workflow, continues through the remaining document flow steps invoking any flow steps of the internal business process flow along the way. At each document flow step, the execution control checks to see if there is an internal business process flow associated with this particular document flow step as shown in Figure 2. If there is, the execution control carries out or executes all the flow steps of the internal business process flow and then returns control back to the document flow step. Once a document flow step is created, it can continue to evolve as business requirements change. New flow steps of the internal business process flow can also be added to or removed from the document flow step; existing flow steps of the internal business process flow can be reconfigured. As shown in Figure 2, the system adds an email entry on the email notification table at every document or internal business flow step. Then, the daemon of an email notification service will send out emails to request those users required to act on the task to process this flow step within 3 to 15 minutes.

For those types of electronic contracts that also involve the internal workflows of other enterprises or contracting parties, the contract administrators can invite their counter parts of the other enterprises to configure the intra-enterprises workflows to process these types of electronic contracts together. The ownership of each intra-enterprise workflow step is designated to one of the enterprises or contracting parties involved. In addition, each intra-enterprise workflow step can be extended to include the internal business process workflows of the other enterprise. These internal business process workflows are treated as private and proprietary processes for the other enterprise that owns this particular intra-

enterprises workflow step. In order to provide access control, each intra-enterprise workflow step is also assigned an access control list to govern a user’s right to view an electronic contract document or to perform any tasks on an electronic contract.

5. A daemon of an email notification service

Figure 3 is a flow diagram illustrating the daemon of

an email notification service. First, the service daemon has to access the database parameters, such as database name and password, for database connection from an application property file. Then, it uses these database parameters to access the database and retrieves the timer and email server parameters. With the timer parameters, such as wakeup interval, it starts the timer. The wakeup interval is usually set around three to 15 minutes. If the interval is set less than 3 minutes, the service daemon may find no email waiting for it to send out. This will simply waste of computing resource. If the interval is set longer than 15 minutes, the service daemon may find too many emails already there waiting for it send out. The service daemon may not be able to finish processing all of emails before the next timer ticks. In this case, the email notification service may have slowed down the contract transaction and lowered the performance of this email driven electronic contract management system in processing electronic contracts because users are waiting for their emails informing them to act. They take actions and act on certain tasks on their electronic contracts according to instructions outlined in the emails they have received. The email also includes an URL link for users to access directly to the Web page where they can act on their tasks on their electronic contracts instead of navigating through many other Web pages to locate the specific Web page with the task that they should act.

For each timer ticks, the service daemon monitors the

notification table and selects those ready to send emails

152152152

by their tenant identification numbers, contract identification numbers, and message types. For each ready to send email, the service daemon accesses the corresponding tenant database according to its tenant identification number. According to the message type, the service daemon retrieves the corresponding message from the message table, the corresponding subject line, prolog and epilog from the content table. Based on the contract identification number, the service daemon retrieves all the contract attributes, such as status, expiration date and parties involved in this electronic contract from the attribute table. Then, the service daemon retrieves enterprise identification numbers of all the parties involved in this electronic contract from the party relationship table. According to the enterprise identification numbers, the service daemon retrieves all user identification numbers required to receive this email as To:, CC: and BCC: receivers from the enterprise table. Based the user identification numbers, the service daemon retrieves their first names, last names and email addresses from the user table. Finally, the service daemon composes the email content with all the above information retrieved and sends out the email with standard Java Mail APIs using a SMTP server as an email server. If the email is sent out successfully, the service daemon will delete this email entry in the notification table so that it will not be resend again. Otherwise, the service daemon will simply sleep until next timer tick.

More than twenty different types of email messages are also send to the contract users. Emails with reminder messages are sent out to users to remind them to act on their tasks. Emails with warning messages are sent out to warm users about their soon to be expired contracts so that they can renew their contracts ahead of expiration date or plan to do something about their expired contracts. Emails with changed contract status messages are sent out to users to inform them the status of their contracts have been changed, such as from passive to active, from active to expired, from expired to retention, from retention to removal. Emails with error messages are sent to users to inform them about their actions on their electronic contracts encounter some errors or problems. Emails with special messages are also sent to users to inform them about specific issues, such as the system is down or scheduled to be unavailable in certain periods. In addition, the email notification module allows authorized users to track, retrieve and resend old emails.

6. Document management, data extraction and search

Electronic contract document management usually involved a large number of complex manual steps. These manual steps are often tedious and may cause security

faults. In addition, an electronic contract can encompass a large number of collateral contract documents including master and customer agreements, supplements, addenda and the like. Therefore, there are a large number of complex and often tedious manual steps involved in the merging of individual documents into an electronic contract. As a result, the merging process is very inefficient and frequently subject to human error. A separate and independent merge tool for electronic documents has been developed to handle and automate the above document merging tasks and its detail description has been reported [11]. The document management module calls the APIs of this document merge tool to carry out a number of document management tasks, such as merging several documents together, assigning new page numbers for the merged document, creating a new document for signing information, and execution or transaction history.

Moreover, data extraction and thus data mining for these electronic contracts composed of a number of different types of semi-structure documents is very difficult. A novel method to extract contract data automatically from a composed document consisted of several electronic contract related documents has been developed and reported [12]. The data extraction and search module calls the APIs of this automatic data extraction system for electronic contract documents to extract specific metadata of the electronic contract and propagates them into the contract metadata tables. When the contract user creates a new electronic contract based on an old electronic contract from an electronic contract template, the document module can automatically retrieve and propagate these useful old metadata into the new electronic contract template. The data extraction module has also found to be very accurate, efficient and useful in extracting contract data for search and data mining, as well as for revenue forecast and profit optimization. 7. The algorithm of signing an electronic contract

When a user signs an electronic contract on-line by

clicking the “I agree”, “I accept”, “Sign”, or any similar buttons representing acceptance, the electronic signature module captures and gathers most required signing information from the signer’s computer using the URL get or post method through the Internet or other on-line electronic processes. The electronic signature module also retrieves the rest of the required signing information from the user’s records stored in the user table of the database. The signing information comprises at least the signer’s name, the signer’s company, and the date or timestamp of the signing. Moreover, the signing information can include the signature of a single party or of a plurality of

153153153

parties involved in the signing of an electronic contract. Thus, the electronic signing information consists of many signing data entries. The electronic signature module stores these signing data entries as contract metadata in the database.

After all required parties involved in an electronic

contract have signed an electronic contract on-line; the signed electronic contract will officially become a legally signed contract document even though none of the required signatures or electronic signing information appeared on its signature blocks. However, there is still a need to add the electronic signing information into the signed electronic contract document so that the contract users can distinguish between a signed and an unsigned electronic contract document as in an electronic or paper copy. Moreover, most contract administrators and representatives, and their customers want the electronic signing information added automatically into the signature blocks of a signed electronic contract document to save time, to have a uniform format, and to avoid mistakes and security faults. The contract administrator can customize the standard signing information format used in their enterprise in the administration module.

Figure 4 is a flow diagram illustrating the algorithm of signing an electronic contract. Once all required parties involved in an electronic contract have signed the electronic contract on-line, the electronic signature module retrieves all the signing information from all signed parties from the contract metadata in the database. The electronic signature module uses the retrieved signing information to compose a signature page as a legal electronic contract signing record and stores in the contract document repository. The electronic signature module also retrieves the signed electronic contract and temporarily removes the document security. Then, the electronic signature module superimposes the signing data entries as watermark on this signed electronic contract. Finally, document security is restored or added

back to the signed electronic contract with watermark to prevent any modifications. 8. Electronic contract life cycle management

Figure 5 is a flow diagram illustrating the electronic

contract life cycle management service daemon. First, the service daemon has to access the database parameters, such as database name and password, for the database connection from a property file. Then, the service daemon uses these database parameters to access the database and retrieves the timer parameters. With the timer parameters, such as wakeup interval, it starts the timer. The wakeup interval is usually set around 24 hours to 1 week. If the interval is set less than 24 hours, the service daemon may find there is no task waiting for it to carry out. This is simply a waste of computing resource. If the interval is set longer than 1 week, users may find that the electronic contract management system does not keep the status of all the electronic contracts up to date.

For each timer tick, the daemon monitors the contract

table and select those pending, rejected, soon to be expired, already expired and beyond retention period contracts by their tenant identification numbers and contract identification numbers. For each select electronic contract, the service daemon accesses the corresponding tenant database according to its tenant identification number. According to the contract identification number, the service daemon retrieves the warning and retention periods from the customization table. Then, the service daemon will activate a pending contract by changing its status from passive to active. For rejected electronic contract, the service daemon removes the rejected contract, cleans up its associated attributes and workflow steps from the database. For the soon to be expired electronic contract, the service daemon adds an email entry on the notification table if the number of days before its expiration days matches one of the warning

154154154

periods. The warning periods usually set to be 3 days, 7 days and 21 days. Emails of this message type are to remind users that they should prepare to renew their contracts or to plan for alternative solutions before their contracts actually expire. For the already expired contract, the service daemon moves the electronic contract from the active to archive contract database, and cleans up its attributes and workflow steps. For the beyond retention contract, the service daemon deletes this expired electronic contract from the database.

9. Implementation and Industrial Experience

Most of the features and functions of this Web-based and email driven electronic management system have been implemented and supports six phases of contract life cycle: request for proposal, quote, negotiation, execution, active and archive contract.. The Adobe PDF library APIs are used to merge several documents into one, create new PDF documents, parse and extract data from PDF document in this system. However, other PDF parsers from third parties can also be used. This electronic contract management system is being used by IBM global service division in several IBM pilot programs. As this electronic contract system supports both internal and intra-enterprises workflows, and multi-tenants hosting capability, IBM can host the system as a service provider to a number of enterprises at the same time in each pilot program to minimize the cost of providing the electronic contracting services by sharing a set of computing servers, such as a number of IBM Websphere middleware products.

Our industrial experience has confirmed the stability and usefulness of this electronic contract management system based on feedbacks from the contract users. It has found to reduce cycle time and costs of contract transactions because of the email notification service. It enhances productivity of sales and support teams in managing their electronic contracts. It saves a lot of time for the contract users, increases their efficiencies and productivities by simplifying and automating many contract tasks, such as merging several documents with new page number and life cycle management. It has also found to improve customer satisfaction by using just one document in a standardized format instead of several documents of different format to represent an electronic contract, and using a standardized format on superimposing the electronic signing information as watermark on the signed electronic contract document. It also minimizes the amount of security exposures of electronic contract documents. Security faults caused by missing or adding the wrong security settings on electronic contracts have been eliminated because the required manual steps for the contract users are replaced with an automatically tasks. It also creates new

opportunities for driving incremental revenue from the search and data mining module.

10. Conclusion and Discussion

This system enables the electronic contract users to accelerate the transaction time and life cycle of their electronic contracts with the email notification service. It enhances the productivity of the contract users by simplifying and automating some manual and tedious contract life cycle management tasks. This system also provides an automated and efficient way for a user to superimpose the electronic signing information as a watermark on a signed electronic contract document in a secure environment. The system allows only authorized users, such as contract administrators, to access the signing data files, thereby preserving the integrity of the signing information. The system can also include a business process for resale of an electronic contract document. For example, the system can limit the original copy to just one copy by adding “copy” or “final copy” or other watermarks to all other copies to avoid third party or business partners for resale. Moreover, the system substantially eliminates the potential for human errors and security breaches in the performance of electronic contract process tasks and the on-line signing document tasks.

This Web-based and email driven electronic contract management system has been deployed in a number of pilots with multiple IBM business units, brands and channels. These pilots presently have more than 500 external customers, business partners, suppliers and around 1000 contract users. Nearly all of them have found their productivities improved, the electronic contract transaction and life cycle accelerated, and contractual errors reduced. The pilot results have confirmed the anticipated benefits, such as reduced time and costs, improved ease of doing business, better tracking and increased business process control, etc. Moreover, it substantially eliminates the potential for human and security breaches in the performance of electronic contract management tasks.

The acceptance of the electronic contract is mainly based on its abilities to cut down expenses, improve turn around time, and enable collaborative tasks with business partners in a secure environment. This Web-based email driven electronic contract management system has enable enterprises to execute and manage their contracts entirely online, eliminating the need to work with paper documents. It has found to reduce the time it takes to complete contracts from days to minutes, driving down processing costs and increasing productivity with anytime, anywhere access to contracts.

155155155

11. Acknowledgment

The authors would like to acknowledge the implementation works done by K. Roy, A. Shah and M. Dharmarajan. The authors would also like to thank G. Pacifici and J. Batstone for their supports. 12. References [1] W.M. McGovern and L. Lawrence, Contracts and Sales: Cases and Problems, Matthew Bender, 1986. [2] International Association of Contract and Commercial Managers, http://www.iaccm.com [3] Y-H Tan and W. Thoen, DocLog: an electronic contract representation language, in Proc. of 35th Annual Hawaii Int’l Conf. on System Sciences, pages 2198-2206, 2002. [4] Z. Milosevic, S. Gibson, P.F. Linington, J. Cole and S. Kulkarni, On design and implementation of a contract monitoring facility, in Proc. of 1st IEEE Int’l Workshop on Electronic Contracting, pages 62-71, 2004. [5] O. Perrin and C. Godart, An approach to implement contracts as trusted intermediaries, in Proc. of 1st IEEE Int’l Workshop on Electronic Contracting, pages 71-78, 2004. [6] M. Iwaihara, H. Jiang and Y. Kambayashi, An integrated system for supporting problem solution in e-contract execution, in Proc. of 1st IEEE Int’l Workshop on Electronic Contracting, pages 9-16, 2004. [7] A. Daskalopulu and T. Maibaum, Towards electronic contract performance, in Proc .of 12th Int’l Workshop on Database and Expert Systems Applications., pages 771-777, 2002. [8] S. Fischmeister, G. Hagleitner and W. Pree, Hermes - A Learn M-Commerce Software Platform Utilizing Electronic Signatures, in Proc of 35th Hawaii Int'l Conf. on System Science, pages 4034-4041, 2002. [9] L. Xu, Monitorable electronic contract, in Proc. of IEEE Int’l Conf. on E-Commerce, pages 92-99, 2003. [10] M. Castellanos and U. Dayal, FACTS: an approach to unearth legacy contracts, in Proc. of 1st IEEE Int’l Workshop on Electronic Contracting, pages 40-45, 2004. [11] T. Kwok and T. Nguyen, A Secure Electronic Contract Management and Process System Automated

with Predefined Tasks, in Proc. of IEEE Int’l Conf. on e-Technology, e-Commerce and e-Service, IEEE Computer Society, pages 276-281, 2005. [12] T. Kwok and T. Nguyen, An Automatic Method to Extract Data from an Electronic Contract Composed of a Number of Documents in PDF Format, in Proc. of IEEE Int’l Conf. on e-Technology, e-Commerce and e-Service, IEEE Computer Society, pages 258-262, 2006.

156156156