microsoft.net based netpaydigilib.library.usp.ac.fj/gsdl/collect/usplibr1/... · every individual...
TRANSCRIPT
MICROSOFT.NET BASED NETPAY
MICRO-PAYMENT SYSTEM FOR MOBILE AND
INTERNET USERS
By
Edwin Sachin Singh
A thesis submitted in partial fulfillment of the
requirements for the degree of
Master of Science
Copyright © 2011 by Edwin Sachin Singh
School of Computing, Information and
Mathematical Sciences
Faculty of Science, Technology and Environment
University of the South Pacific
August, 2011
Declaration
I, Edwin Sachin Singh, declare that this thesis is my own work and that, to the best of
my knowledge, it contains no material previously published, or substantially
overlapping with material submitted for the award of any other degree at any
institution, except where due acknowledgements is made in the text.
Signature ……………………..................... Date……10/05/2011…………………
Name……Edwin Sachin Singh………..…………………………………………….
Student ID……S11010969……………………………………………..……………
The research in this thesis was performed under my supervision and to my knowledge
is the sole work of Mr. Edwin Sachin Singh.
Signature……………………………………..Date…….10/05/2011……….………
Name….Dr. Sharlene Xiaoling Dai…………………………………………….……
Designation……Senior Lecturer......………………………………………………..
i
Acknowledgement
I am heartily thankful to my supervisor, Dr. Xiaoling Dai, whose supervision,
encouragement, guidance and support from the initial to the final level enabled me to
successfully complete this thesis. Secondly, I am thankful to my wife and parents for
their motivation and support.
Lastly, I offer my regards and blessings to all of those who supported me in any
aspect during the completion of this write-up.
Edwin Singh
ii
AbstractMicro-payment systems are becoming an important part of M-Commerce world. Due
to the invention of new and cheaper wireless technologies such as mobile phones,
PDAs and other handheld devices, the number of people adapting to wireless
communication are increasing significantly. To make micro-payment accessible by
every individual we describe the prototype architecture of Mobile and Electronic
Commerce (M&E) Netpay systems on the Microsoft.NET platform for interconnect
broker and vendors systems using Web Services. This is an offline, debit based
protocol that provides a secure, flexible, usable and reliable credit service over the
internet ensuring fair participation by all parties. The main features of M&E-NetPay
protocol are interoperability and mobility. We presented an object oriented design and
describe the prototype implementation of M&E-NetPay for ringtone and wallpaper
sites. The architecture of the .NET framework application development is also
described. We have carried out an assessment of most recent CORBA based off-line
micro-payment model using light-weight hashing-based encryption with the .NET
based M&E-Netpay micro-payment system. We reported on the design of our
experiment and results of end user evaluation. We discussed the advantages of our
model compared to the CORBA based micropayment system. We set up the heuristic
evaluation performed by a set of evaluators and presented directions for research
aiming to improve the overall satisfaction and efficiency of our model for mobile and
internet users. The evaluation users were satisfied with the use of .NET based M&E-
Netpay. The recommendations of heuristic evaluators were implemented. Performance
impact and usability evaluation also favored M&E-Netpay system.
iii
Table of ContentsAbstract ................................................................................................................................................ ii List of Publication(s) from the thesis ........................................................................................ viii Chapter 1: Introduction .................................................................................................................... 1
1.1 Motivation ............................................................................................................................... 1
1.2 Our Research .......................................................................................................................... 3
1.3 Thesis Outline ........................................................................................................................ 4
Chapter 2: Background and Prior Work ...................................................................................... 5
2.1 Overview ................................................................................................................................. 5
2.2 Main properties of M&E Micro-payment system ......................................................... 6
2.2.1 Security ............................................................................................................................ 6
2.2.2 Privacy/Anonymity ...................................................................................................... 6
2.2.3 Validation (online/offline) and communication load ........................................... 7
2.2.4 Ease of use ...................................................................................................................... 7
2.2.5 Transferability ................................................................................................................ 7
2.2.6 Scalability ....................................................................................................................... 7
2.2.7 Interoperability .............................................................................................................. 7
2.3 Existing Micro-payment systems ...................................................................................... 8
2.3.1 Online vs. Offline operation ....................................................................................... 8
2.3.2 CORBA vs. Web Service ............................................................................................ 8
2.4 Cryptography Technologies ............................................................................................. 10
2.4.1 Secret key (or symmetric) Cryptography .............................................................. 10
2.4.2 Public-Key (or asymmetric) Cryptography .......................................................... 11
2.4.3 Cryptographic Hash Function .................................................................................. 11
2.5 Micro-payment models in (M&E) commerce ............................................................. 12
2.5.1 MPS ................................................................................................................................ 12
2.5.2 CMP ............................................................................................................................... 15
2.5.3 NetPay ............................................................................................................................ 18
2.5.4 Payment model comparison ..................................................................................... 19
2.6 Other Web Technologies ................................................................................................... 24
2.6.1 .NET Framework Architecture ................................................................................ 24
2.6.2 Web Services................................................................................................................ 25
2.6.3 ASP.NET ...................................................................................................................... 27
2.6.4 Active Server Pages (ASP) ....................................................................................... 27
2.7 Summary ............................................................................................................................... 28
iv
Chapter 3: M&E-NetPay Protocol and System Requirements ............................................ 29
3.1 M&E-NetPay Protocol ....................................................................................................... 30
3.2 Payment System Comparison .......................................................................................... 35
3.3 M&E User Requirements and Use Cases ..................................................................... 38
3.3.1 Use Case Diagram ...................................................................................................... 40
3.3.2 Use Case Descriptions ............................................................................................... 41
3.4 Non-functional Requirements .......................................................................................... 47
3.5 M&E-NetPay OOA Modelling ........................................................................................ 48
3.5.1 Class Modelling ........................................................................................................... 48
3.5.2 Sequence Modelling ................................................................................................... 51
3.6 Summary ............................................................................................................................... 57
Chapter 4: M&E-NetPay Architecture and Design ................................................................ 58
4.1 M&E-NetPay Software Architecture ............................................................................. 58
4.2 M&E-NetPay Software Deployment Architecture ..................................................... 61
4.3 M&E-NetPay Object Oriented Design .......................................................................... 62
4.3.1 Static System Design ................................................................................................. 62
4.3.1.1 M&E-NetPay E-wallet ...................................................................................... 62
4.3.1.2 M&E-NetPay ....................................................................................................... 64
4.3.1.3 Broker OOD class diagram .............................................................................. 65
4.3.1.3.2 Buy E-coin Objects .................................................................................... 68
4.3.1.3.3 Redeem e-coins Objects ........................................................................... 70
4.3.1.4 M&E-Vendor OOD diagram ........................................................................... 71
4.3.1.4.1 Transfer T&I Objects ................................................................................ 71
4.3.1.4.2 Search Wallpaper Objects ........................................................................ 73
4.3.1.4.4 Redeem Spending ....................................................................................... 75
4.3.2 Dynamic System Design ........................................................................................... 77
4.3.2.1 Buy e-coins ........................................................................................................... 78
4.3.2.2 Download File ..................................................................................................... 79
4.3.2.3 Redeem Spending ............................................................................................... 80
4.4 Database Design .................................................................................................................. 81
4.4.1 Broker database ........................................................................................................... 81
4.4.2 Vendor Databases ....................................................................................................... 82
4.4.2.1 Wallpaper Database ....................................................................................... 82
4.5 M&E NetPay Implementation ......................................................................................... 85
4.5.1 Broker ............................................................................................................................ 85
4.5.2 Vendor ........................................................................................................................... 87
v
4.5.3 Customer (M&E User) .............................................................................................. 88
4.6 Implementation and Experience ...................................................................................... 88
4.7 Summary ............................................................................................................................... 89
Chapter 5: Evaluation .................................................................................................................... 90
5.1 Motivation ............................................................................................................................. 90
5.2 Performance Impact Evaluation ...................................................................................... 91
5.2.1 Procedure ...................................................................................................................... 91
5.2.2 Results ............................................................................................................................ 92
5.3 Heuristic Evaluation ........................................................................................................... 94
5.3.1 Design ............................................................................................................................ 95
5.3.2 Results ............................................................................................................................ 96
5.4 Usability Evaluation ........................................................................................................... 98
5.4.1 Design .......................................................................................................................... 100
5.4.2 Results .......................................................................................................................... 101
5.5 Summary ............................................................................................................................. 102
Chapter 6: Conclusion and Future work ................................................................................. 103
6.1 Contributions ...................................................................................................................... 103
6.2 Conclusion .......................................................................................................................... 105
6.3 Future work ......................................................................................................................... 108
Reference ........................................................................................................................................ 110
Appendix A: Heuristic Evaluation ........................................................................................... 117
Appendix B: Usability Testing .................................................................................................. 128
vi
Figures and Tables
FiguresFigure 2-1 Basic client and server components from interface for Web Services
and CORBA
9
Figure 2-2 Multiparty Payment Scheme model for Ad Hoc Network 15
Figure 2-3 Basic Chaotic Micro-payment Protocol 17
Figure 2-4 NetPay Micro-payment Model 19
Figure 2-5 An overview of .NET architecture 25
Figure 3-1 M&E NetPay interactions 33
Figure 3-2 Basic M&E NetPay interactions 41
Figure 3-3 Example Mobile user registration 42
Figure 3-4 Example of mobile user buying e-coins 44
Figure 3-5 Mobile user downloading ring tone from the vendor site 46
Figure 3-6 M&E-NetPay micro-payment system class diagram 49
Figure 3-7 Register and buy E-coins sequence diagram 52
Figure 3-8 Buy ring tone with vendor1 sequence diagram 53
Figure 3-9 Buy wallpaper with vendor2 sequence diagram 55
Figure 3-10 Redeem E-coins with broker sequence diagram 56
Figure 4-1 Basic Software Application Architecture 60
Figure 4-2: Basic M&E-NetPay Deployment Architecture 61
Figure 4-3 M&E-NetPay e-wallet design feature 64
Figure 4-4 Register class diagram 66
Figure 4-5 Buy e-coin class diagram 68
Figure 4-6 Redeem E-coin class diagram 70
Figure 4-7 Transfer Touchstone and Index class diagram 72
Figure 4-8 Search Wallpaper class diagram 73
Figure 4-9 Download Wallpaper class diagram 75
Figure 4-10 Redeem spending e-coins with broker 76
Figure 4-11 Buy e-coin sequence diagram 78
Figure 4-12 Download wallpaper sequence diagram 79
Figure 4-13 Redeem spending sequence diagram 80
vii
Figure 4-14 Broker System database ERD 81
Figure 4-15 Wallpaper system database ERD 83
Figure 4-16: Ringtone system database ERD 84
Figure 4-17: Code for Web Service references on the broker web application 85
Figure 4-18: M&E users purchasing e-coins from broker 86
Figure 4-19: M&E User spending e-coins at the Ringtone site 87
Figure 5-1 Response delay time of downloading wallpaper 93
Figure 5-2 Usability Test Results on Usability features 101
TablesTable 2-1 Comparison of M&E micro-payment models 22
Table 3-1 Comparison of M&E-NetPay with other micro-payment models 35
Table 3-1 Register Use Case 42
Table 3-3 Buy E-coins Use Case 43
Table 3-4 Debit E-coins Use Case 45
Table 3-5 Redeem E-coins Use Case 46
Table 5-1 Results of Downloading Wallpaper 92
Table 5-2 Results of Searching Wallpapers, Buying and Redeeming E-coins 94
Table 5-3 Details of Heuristic Employed 96
Table 5-4 Severity of heuristic evaluation 96
Table 5-5 Summary of Findings 97
Table 5-6 Guidelines of usability evaluation 99
Table B.1 Results for M&E-NetPay micropayment system 135
Table B.2 Results for CORBA-based NetPay micropayment system 146
viii
List of Publication(s) from the thesis1. Singh, E. and Dai, X.: Web Service-based Netpay Micro-payment System for Mobile
and Internet Users, Proceedings of International Conference on Data Engineering and
Internet Technology (DEIT 2011), 15-17 March 2011, Bali, Indonesia, IEEE
Computer Society Publisher.
1
Chapter 1: Introduction
1.1 Motivation
Mobile commerce is the conduct of business and services over portable, wireless
devices. Due to the astronomical growth of Internet users, maturation of Internet
technologies, realization of Internet’s capabilities, the power of electronic commerce,
and the invention of wireless communication technologies and devices, mobile
commerce has rapidly attained the business vanguard. Similar to electronic
commerce, m-commerce application can be Business-to-Business (B2B) and
Business-to-Consumers (B2C) or any other of the classifications available with e-
commerce world. Since mobile devices are always with the customer no matter
where they travel, the ease to purchase goods and services is always at hand. It is a
more convenient way for customers to purchase goods and services. M-commerce
will not only benefit business to raise their revenue but it will also benefit customers
in terms of time and travel cost.
M-commerce will bring a major service gap in developing countries that is critical to
their social and economic development. For customers it is an opportunity to become
engaged in the formal banking sector, enable high volume, low-cost transaction per
item and eliminate risks associated with the use of cash such as theft. Banks will be
able to provide further services to customers and migrate them upwards to use
banking services. Vendors will have greater sales of goods and services without any
extra cost. Micro-finance institutions (i.e. broker) will act on behalf of a bank to
provide services to customers such as managing their money account and facilitating
micro-payments across multiple vendors. Moreover some of the most common
advantages to businesses and customers include:
� Reachability: access on your demand from anywhere.
� Convenience and accessibility: this is no time and space limitations and people
can access applications during their preferred time.
� Security: use of Security Socket Layer (SSL) to provide personal security,
privacy of communications, and data integrity.
� Localization: merging capabilities and sharing costs between vendors wishing to
'push' or promote mutual services and products.
2
� Instant connectivity: access to applications on demand using multiple
technologies and more network option.
� Personalization: use of existing technology to receive what you want, when and
how you want.
There are many m-commerce scenarios in existence and potential roles of using
wireless devices to access the web is enormous. Therefore, m-commerce demands an
appropriate payment method and in order to allow "pay-per-use or service" of such
content [2]. A suitable micro-payment protocol should provide high-volume, low-
cost transaction per item information from vendors. There are several micro-payment
protocols proposed for electronic payment in mobile commerce in recent years [4, 5,
7, 8, 9]. However some of these proposed schemes are not suitable for multiple
vendors because future mobile systems will involve a large number of users, which
will access a variety of information, services and commodities provided by a range
of content providers. The NetPay micro-payment model and architecture been
developed provides an off-line micro-payment model using light-weight hashing-
based encryption using CORBA interfaces as middleware for interconnect broker
and vendor sites [3]. This prototype is extremely suitable for e-commerce
applications. However, in a mobile environment a client (and possibly the server)
keeps moving which requires dealing with changing network addresses and
unreliable connections. For this kind of scenario, CORBA is not well-suited. The
mobility factor creates some additional constraints because of CORBA’s tight
coupling between clients and servers. We have modified the NetPay software
architecture by replacing CORBA middleware with Web Services.
3
Software architecture defines a structured solution that meets all of the technical and
operational requirements, while minimizing common quality attributes such as
performance, security, manageability, reliability and flexibility. Software architecture
involves a series of decisions on a wide range of factors, and these decisions can a
have significant impact on the quality attributes and the overall success of the
application. Therefore it plays an important role in the system development.
1.2 Our Research
To strengthen the existing NetPay micro-payment protocols, we proposed a new
protocol, named M&E-NetPay that is extended from the existing NetPay protocol
[3]. M&E-NetPay is a secure, cheap, widely available, and debit-based protocol.
M&E-NetPay differs from the previous protocols in the following aspects: M&E-
NetPay is developed on the .NET platform which uses Web Service interfaces as the
middleware. Web Services carry greater advantages than CORBA when developing
mobile applications. Secondly, it caters for a larger number of users as it is available
via web browsers as well as via mobile devices.
We have developed software architecture for M&E-NetPay micro-payment system
which uses Web Service interfaces as the middleware for interconnect broker and
vendor sites for mobile and Internet users. Web Services uses SOAP and simple XML
based protocol to allow broker and vendor applications to exchange information. We
implemented M&E-NetPay on .NET platform for deployment with thin-client vendor
interfaces i.e. HTML and WML-based interfaces for customers. M&E-NetPay is fully
distributed multi-tier system which is deployed over multiple servers to allow minimal
downtime and maximal competence. M&E-NetPay architecture also supports servers
running on different platforms and broker and vendor applications being developed
using different programming languages. We describe a prototype implementation of
M&E-NetPay on .NET framework 4.0 using C# language, Active Server Pages
(ASP.NET) and Web Services.
We have carried out three types of evaluations to validate M&E-NetPay system. We
adopt performance impact and heuristic evaluation methods. Performance impact
evaluation is to determine whether adding M&E-NetPay micro-payment to typical
4
vendor web servers would be viable for large transaction loading in M&E environment
while heuristic evaluation examines the M&E-NetPay interface, and judges its
compliance with recognized usability principles (the “heuristics”). The above two
evaluations does not include users working with the product. We conduct a usability
evaluation to determine whether M&E-NetPay is usable as far as target users are
concerned. A usability evaluation focuses users working with the product.
We have analysed the results from these three evaluation approaches to determine if
(1) M&E-NetPay is more usable, scalable and reliable compared to CORBA-based
NetPay; (2) the performance of M&E-NetPay micro-payment would be acceptable by
mobile and internet users; and (3) that any usability issues with M&E-NetPay can be
identified and addressed as part of an iterative design process.
1.3 Thesis Outline
This thesis focuses on the details of micro-payment systems over the internet and
mobile and their implementations. The structure is as follows.
� Chapter 2 presents the requirements for a .NET based M&E-NetPay micro-
payment system in M&E environment. It also presents previously proposed M&E
micro-payment protocols in detail and discussions on their advantages and
disadvantages.
� Chapter 3 introduces a Web Service-based M&E-NetPay micro-payment
protocol. This chapter contains description, and explanation of the protocol with
illustrations. It compares M&E-NetPay approach with several other micro-
payment protocols.
� Chapter 4 describes Web Service-based M&E-NetPay system designs and
implementations which includes the M&E-NetPay broker and M&E-NetPay
vendors.
� Chapter 5 describes the performance impact evaluation, heuristic evaluation and
usability evaluation of M&E-NetPay prototype.
� Chapter 6 presents a general discussion about M&E-NetPay micro-payments
thereby describes the contributions of this research and providing an outline for
future work.
5
Chapter 2: Background and Prior WorkExisting micro-payment systems are popular and most widely used for e-commerce
today. They provide support for heavy weight credit card and digital cash payments
that are suitable for high-volume, low value transactions. These payment schemes are
based on online, time-of-payment authorization and require the use of heavy weight
encryption technologies. However, Micro-payment systems have the potential to
provide high volume and low value pay-as-you-go transactions for a wide variety of
mobile applications [6].
Several micro-payment schemes are proposed for electronic payment in mobile
commerce such as Mobile-Millicent, MPay, Huang’s Protocol, Token-based
Protocol, Payword and Mobile-NetPay Protocol [1, 34]. CORBA-based NetPay
protocol enhances a more flexible micro-payment scheme that will deploy the broker
(a trusted micro-finance company) to ensure payments are not based on assumption
of continuous connectivity and for real time payment transaction. CORBA-based
NetPay uses a single hash chain that provides high efficiency for payment of low-
value and high frequency transaction in mobile commerce [1]. This chapter will
briefly discuss the effectiveness and efficiency of some M&E micro-payment
protocols and outline some cryptographic primitives required for the understanding
of current payment protocols.
2.1 Overview
Based on the server-side e-wallet NetPay protocol, we propose an adaption to M&E-
NetPay protocol that is suitable for mobile and Internet environments. Our M&E-
NetPay protocol uses touchstones that are signed by the broker and an e-coin index
signed by requesting vendors. The signed touchstone is used by a vendor to verify
the electronic currency – paywords, and signed Index is used to prevent double
spending by M&E users and to resolve disputes between customers and vendors.
M&E-NetPay is a secure, cheap, widely available, and debit-based protocol.
With the invention of new wireless technologies and increase number of mobile and
internet users, mobile commerce became evident. Users are able to purchase goods
6
and services via mobile and internet. However, macro-payment method was not
effective and efficient but very costly. It was not suitable to spend large numbers of
small amounts of money [3]. Later, NetPay micro-payment was introduced with
CORBA interfaces as middleware which resulted into different problems such as
mobility, accessibility and interoperability.
2.2 Main properties of M&E Micro-payment system
We will use some key properties of security, privacy/anonymity, validation
(online/offline), ease of use, transferability, scalability and interoperability to assess
the M&E micro-payment system [1]. The following section briefly describes these
properties.
2.2.1 Security
Security is the single most important service that banks and mobile commerce
providers offer to their customers [14]. Micro-payment security may consist of:
� Authentication - provides ability to determine the validity of a user’s identity via
password or digital signature. Authentication is used on the basis for
authorization (determine whether the access will be granted or non-repudiation
(proving that a party engaged in a transaction is the correct one using digital
signatures.) [15].
� Fast hashing functions – converts set of characters into shorter fixed-length to
represent the actual value. It is used to index and query items from a database as
shorter hashed keys are faster to find. Hashing functions are one-way operation
hence it should not produce the same hash value from two different inputs.
M&E-NetPay uses hash functions to verify the index from the touchstone and
prevent customers from double spending.
2.2.2 Privacy/Anonymity
Refers to the protection of personal and payment information and it also entails the
protection of the identities of the participating parties (broker, vendors and
customers) in a payment protocol especially with respect to customers or mobile
users. Anonymity is a fundamental requirement for privacy aware systems.
7
2.2.3 Validation (online/offline) and communication load
The payment system should be able to process payment without the need for online
contact with the broker for verifying the payment tokens during transaction. Online
validation requires a broker to validate payment token each time a transaction is
made. Hence the frequency of communication between the broker and user increases
transaction cost and communication load.
2.2.4 Ease of use
It is the ability of M&E users to use the system easily without familiarizing with the
M&E user interfaces or involve in any type of authentication at all times.
2.2.5 Transferability
The e-coins used for payments should be transferable between multiple vendors. This
allows the users to use the same e-coins to make payments across multiple vendors.
2.2.6 Scalability
The load of communication and transaction of any entity must not grow to an
unmanageable size. The load should be distributed among the vendors rather than the
broker. Payment system should be able to cater for the rapidly growing number of
users without showing a negative impact on the performance.
2.2.7 Interoperability
Interoperability is the ability of a system to operate in conjunction with other
supporting protocols, hardware, software, application and data layers. Interoperability
minimizes the complexity of software development by reusing components
(components within the system) and performing inter-component (components
between systems) communication. Interoperable systems are language and platform
independent. (i.e. a client application can be programmed in C# and running on
Windows platform, while the Web Service is programmed in Java and running under
Linux).
8
2.3 Existing Micro-payment systems
Micro-payments are financial transaction that involves very small amount of money.
Still today, micro-payments are not very efficiently used. A wide range of micro-
payment protocols are in the literature review and some of them are on commercial
trial. While some companies have extended their businesses to use micro-payment
systems, there are many companies who still have doubts on existing micro-
payments’ performance, scalability, and security.
Currently, the most efficient micro-payment systems are within MMORPGs
(massively multi-player online role-playing games), and Virtual Life Sims (such as
Second Life). These systems use a means of credits that are usually correspondent to
some amount of real money to buy and sell things in the game [18].
2.3.1 Online vs. Offline operation
Payment systems are classified as either online or offline [19]. In an online payment
system, every transaction needs to be authorized by a bank/broker that issues e-coins
in order to prevent double spending by customers. Hence a bottle neck problem is
introduced. A single point of transaction will cause transaction traffic clogging and
delay in payment. Huang [1], Millicent [20], Micro-iKP [21], Digicash [18] and
NetBill [23] are all online systems which require the broker to check all transactions.
Huang, Millicent and Micro-iKP systems downgrades the scalability of the system
and Digicash and NetBill has worse performance but provide better security.
An offline protocol does not rely on a third party to guard against double spending.
Offline protocols are NetPay [23], Mini-pay [27], Payword and MicroMint [9]. Most
of these are credit based since the purchase is made available to the customer and
he/she is debited with the payment. In a credit based system there is no protection
method to prevent customer from double spending or over spending.
2.3.2 CORBA vs. Web Service
We have developed NetPay-based systems for client-server broker, vendor and
customer networks [3, 26]. The broker application server provides a set of CORBA
9
interfaces vendor application servers communicate with to request touchstones and
redeem e-coins [3]. CORBA enables the client to invoke methods on remote objects at
the server independent of the language the objects have been written in, and their
location. The interaction between client and server is mediated by Object Request
Brokers (ORBs) on both a client and a server sides. Problems with this protocol are
that every node of CORBA in the application environment would need to run the same
ORB product. Now there are cases where CORBA ORBs interoperate from different
vendors. However, the interoperability does not extend into higher-level services such
as security and transaction management. Furthermore, any vendor specific
optimizations would be lost in this situation. In addition this protocol depends on a
closely administered environment thus the probability of two random computers being
able to successfully make Distributed Component Object Model (DCOM) or Internet
Inter-ORB Protocol (IIOP) calls are relatively low [27]. Lastly, CORBA is reasonable
protocol for server-to-server communications. However, it has severe weaknesses for
client-to-server communications, especially when client machines are scattered across
the Internet.
Figure 2-1 Basic client and server components from interface for Web Services
and CORBA
A more improved approach is to replace CORBA middleware with Web Services.
Web Services are an emerging distributed middleware technology that uses SOAP and
10
simple XML based protocol to allow applications to exchange data across the web.
Web Services offers new programming model for building distributed applications
using open internet standards. This new technology maneuvers the openness of
specific internet technologies to address many of the interoperability issues of
CORBA. Most Web Services use Hyper Text Transfer Protocol (HTTP) for
transmitting messages. This is a major advantage for building an Internet-scale
application like M&E-NetPay system, since most of the Internet's proxies and firewalls
will not trouble with HTTP traffic unlike CORBA, which usually has trouble with
firewalls.
Moreover, Web Services are platform-independent and language-independent. A
client program can be programmed in C# and running under Windows, while the Web
Service is programmed in Java and running under Linux.
2.4 Cryptography Technologies
Cryptography is the art of secret writing (encryption), reading secret writing
(decryption) and penetrating the secret key writing of others (cryptanalysis) [28]. The
cryptography codes are used to convert data so that only specific recipient will be able
to read it using a key [29].The unencrypted data is referred to as plaintext. The
encrypted data is ciphertext. Some of the specific security requirements of
cryptography include authentication (process of proving once identity),
privacy/confidentiality (ensuring that no one can read the message except the intended
receiver), integrity (assuring the receiver that the received message has not been
altered in any way from the original) and non-repudiation (mechanism to prove that the
sender really sent this message). We briefly outline some cryptography techniques
required for the understanding of some payment protocols. There are, in general, three
types of cryptographic schemes typically used to accomplish these goals: secret key (or
symmetric) cryptography, public-key (or asymmetric) cryptography, and hash
functions [30].
2.4.1 Secret key (or symmetric) Cryptography
Secret key cryptography uses a single key for encryption and decryption. This single
key must be known to both the sender and the receiver. Secret key cryptography
11
schemes are generally categorized as being either stream ciphers or block ciphers. Data
Encryption Standard (DES) is the most common secret key cryptography algorithm
being used today. DES is a block-cipher employing 56 bit key that operates on 64 bit
blocks. The problem with the use of symmetric cryptography is communication
between two parties in a secure network. In order to solve the above problem public
key cryptography are proposed [30].
2.4.2 Public-Key (or asymmetric) Cryptography
In public key cryptography two distinct keys are used: a public key to perform
encryption and a private key to perform decryption [31]. It is a fundamental and widely
used technology, and enables secure transmission of information on the Internet. This
allows anyone to encrypt a message but only individuals with the corresponding
private key to decrypt messages. Public cryptography also overcomes the distribution
problem because only public keys need to be sent over the insecure network; private
keys are maintained locally. Public-key cryptography employs two keys that are
mathematically related although knowledge of one key does not allow someone to
easily determine the other key. One key is used to encrypt the plaintext and the other
key is used to decrypt the ciphertext. It does not matter which key is applied first but
both the keys are required for the process [30].
In Public-key cryptography the keys are designated as public key and can be presented
any way the owner wants. The other key is designated as private key and is never
known to another party. Suppose A wants to send a message to B. A encrypts some
information using B's public key; B decrypts the ciphertext using his/her private key.
This method could be also used to prove who sent a message; A, for example, could
encrypt some plaintext with his/her private key; when B decrypts using A's public key,
he/she knows that A sent the message and A cannot deny having sent the message. The
most common public-key algorithm in use today is RSA algorithm developed by three
MIT mathematicians Ronald Rivest, Adi Shamir, and Leonard Adleman [30].
2.4.3 Cryptographic Hash Function
Cryptographic hash functions are also called message digest and one- way encryption
which uses no key. Instead, fixed-length hash value is computed based upon the
12
plaintext that makes it impossible for either the contents or length of the plaintext to be
recovered. Hash functions also provide digital fingerprint of a file’s content and
ensures that the file has not been altered by an intruder or virus. Many operating
systems also prefer hash functions to encrypt password [30] Examples of hash
algorithms includes MD4, MD5, RIPEMD-160, SHA-1, SHA-256, SHA-384 and
SHA-512 [33].
The minimum properties that a cryptographic hash function must have are [32]:
� Preimage resistance - given a hash ‘h’ it should be difficult for any message ‘m’
such that h = hash (m). Functions that lack this property are vulnerable to preimage
attack.
� Second preimage resistance - given any input ‘m1’ it should be difficult to find
another input ‘m2’ where m1 not equal to m2 such that hash (m1) = hash (m2).
Functions that lack this property are vulnerable to second preimage attack.
� Collision resistance – it should be difficult to find two different messages’m1’ and
‘m2’ such that hash (m1) = hash (m2)
Hash functions have proved to be better than the public-key and secret-key
cryptography in terms of speed and security. Hence it meets our requirement for
micropayment systems. However, some micro-payment schemes require using public
key cryptography in order to minimize communication costs such as PayWord and
other protocols. Therefore it is important to greatly reduce the number of these
operations. A “payword chain” is generated by using a one way hash function and is
going to be used to represent a set of e-coins in the M&E-NetPay system.
2.5 Micro-payment models in (M&E) commerce
Many micro-payment systems are in existence now. We review the key concept of
some of these micro-payment systems and identify their key strength and weakness.
2.5.1 MPS
MPS (Multiparty Payment Scheme) [67] is a micro-payment for ad hoc network that
enables a node to join an existing ad hoc network and allows it to pay each node that
13
relays packets on its behalf in real-time. MPS is a lightweight payment scheme based
on hash chains which is flexible with route changes without the involvement of third
party (such as a bank or broker) to pay the nodes in new path.
2.5.1.1 MPS protocol should meet the following goals of ad hoc network:
� Off-line verification of payment token – the nodes should not require the bank or
broker to always be on-line to verify payment.
� Flexibility in choosing routes – the node should choose the best optimal path to
its destination and pay all nodes along the path for forwarding packets on its
behalf. The broker or bank should not be contacted for any route changes for
preparing a new payment contract for the nodes in new path.
� Lightweight cryptographic procedures – it helps the in-between nodes to quickly
verify payment packet which speeds the payment process.
� Fraud minimization in the system – it uses post-fact detection to identify frauds
and block them from making any communication with the system.
2.5.1.2 MPS payment for packet forwarding includes the following steps:
� Broker commitment
The user establishes an account with the broker. The broker then sends a smart
card to the user loaded with the public key. Before transmitting packets the user
needs to purchase payment chains from the broker. The user sends the encrypted
length of sub-chain and macropayment details to the broker signed by broker’s
public key. The broker sends the payment chains details to the user singed by its
private key and encrypted with the user’s public key. Smart card is used to
decrypt the commitment however it cannot guarantee multiple payment
protection.
� Charge assembly and Endorsement Distribution
In this process the initiating node have knowledge of total cost involved in packet
forwarding. The source nodes also have full information of routes through the
network. The starting node requests the charge from each node by sending a
charge request message. The intermediate nodes return their charge for packet
14
forwarding after signing it with their private key. The broker signed
endorsements are distributed to the cheapest or most optimum route nodes.
� Making Payment
To pay for multiple nodes along the path multiple hash values are not required.
The correct hash values can be rather attached further up the chain. Together with
the hash values the middle nodes also require the corresponding broker signed
endorsement to redeem the tokens.
� Change in Route- New Path
Topology change of the ad hoc network will result in the change of route in fixed
network or other network. Therefore all nodes in the new path still need to be
paid. MPS is flexible enough to cope up with this situation without the need to
engage the broker. The new set of endorsement is distributed to the nodes in the
new path.
� Redeeming Tokens
At the end of the day the nodes send the payment tokens to the broker which they
collected for packet forwarding. The payment token and broker signed
endorsement are encrypted with the broker’s public key. The broker verifies the
payment tokens and credits the nodes’ account.
15
Figure 2-2 Multiparty Payment Scheme model for Ad Hoc Network
MPS design also supports multiple brokers. Off-line verification has made the protocol
more efficient and scalable. However the system is still in danger of limited amount of
fraud. If the topology of the ad hoc network changes there can be wastage of the broker
endorsement which was distributed for the previous path.
2.5.2 CMP
CMP (Chaotic micro-payment protocol) [68] is a micro-payment protocol which is
built on symmetry encryption techniques and chaotic double hash chain. The
protocol construct two PayWord chains, one for the merchant and one for the users
by using iteration process of Henon-like chaotic system. The chaotic hash function is
used to generate payment chain and the use of symmetric algorithm to encrypt
16
transaction information has strengthened the security and efficiency of CMP. CMP is
an off-line system which includes three stakeholders: users, vendors and broker.
The hash function in CMP was implemented on chaotic phenomenon (way of motion
of non-linear dynamical system). There are three main characters of Chaos
dynamical system: sensitivity of preliminary conditions and parameters,
characteristics owned are not interrupted and pseudo- randomicity. To create big
parameter space for big secret key the chaotic hash function was constructed using
Henon-like chaotic mapping. Chaotic hash function is a one-way hash that is simple
but difficult to deduce inversely. It also maps the different length of messages to a
fixed hash value.
The security analysis of chaotic hash function concludes that the encryption
algorithm is strong and stable to satisfy confusion and diffusion ability. Collision
experiments shows that the chaotic hash algorithm has low collision rate and has a
greater capability of avoiding collision. Chaotic hash algorithm also prevents
birthday attack to occur. Birthday attack is the most possible attack for hash function.
In CMP the buyers and sellers needs to register with the broker before they can do
any trade with other vendors and customers. To register with the broker the buyer
sends his/her personal and credit card information encrypted using his/her private
key. The broker creates the customer’s account and sends back the generated ID and
the sharing secret key of the customer in an encrypted message. In order to pay for
purchase the customer creates two hash chains.
The customer needs to send a register application to the broker if he/she needs to
purchase item(s) from the vendor. The broker generates a random identity of the user
and uses his/her sharing secret key to produce a payment certificate. The user then
sends the payment certificate to the vendor to complete registration process.
17
If the customer wishes to make a purchase then he/she needs to select a random
number r from the chaotic hash function range and sends a message to the vendor
after encrypting it with chaotic hash value H(r). Receiving vendor calculates the
chaotic value using r and decrypts the information to view the payment chain. If the
payment chain exists, the vendor tests the PayWord of chain 2 and sends the
encrypted service to the customer. Upon receiving the service the customer makes
the payment. Figure 2-3 shows basic CMP model.
In order to reckon the PayWords the vendor sends an encrypted reckoning message
to the broker. The broker decrypts the message, checks the payment certificate of
double payment chain. If the payment verification is successful the broker transfers
the service fee to the vendor’s account.
Figure 2-3 Basic Chaotic Micro-payment Protocol
18
2.5.2.1 CMP security consists of:
� Anonymity – the vendor cannot view customers ID information.
� Information confidentiality – the information is kept confidential by using shared
key to encrypt the service information which is delivered to the user
� Avoid fraud exchange – nor the vendors or the users benefit from any kind of
fraudulence.
CMP is primarily designed for low value mobile commerce items. The protocol
has greater security and faster operation efficiency.
2.5.3 NetPay
NetPay [3] is a new micro-payment model in the e-commerce environment. It is an
off-line micro-payment system that uses CORBA interfaces to support
communication between broker and vendor applications. NetPay uses fast hashing
functions to improve performance and security issues.
NetPay involves three parties: customers, vendors and a broker. The customer needs
to register with the broker in order to use the service of the vendors. The customer
uses a single macro-payment to enable the broker to generate e-coins of the amount
requested by him/her. The e-coins are generated using light-weight hashing-based
encryption. The e-coins are not vendor specific (i.e. it can be used across multiple
vendors).
When a user purchases an item from the first vendor V1, V1 debits the user’s e-coins.
Before the transaction is completed V1 verifies the user’s e-coins using the
touchstone from the broker. When the user buys item(s) from another vendor V2, V2
requests the touchstone and e-coin index from the user’s previous vendor V1. If e-
coins are verified the purchased item(s) are downloaded onto the user’s machine. If
the user runs out of e-coins, he/she is directed to the broker’s site to buy more e-
coins. The vendors redeem e-coins for real money value from the broker on daily or
weekly basis. The use of encrypted e-coins with associated index value solves the
problem bottle-necking, prevents customers’ from double spending, disallows
vendors from over-debiting, ensures conflict between vendors as well as protects
third-parties from forging e-coins. In NetPay model the customer’s identity is fully
19
hidden from the vendor. That is the vendor has no information of the user who is
using the vendor system. Figure 2-4 shows basic NetPay model.
Figure 2-4 NetPay Micro-payment Model
NetPay micro-payment supports high-volume, low cost transaction per item without
the interaction of broker on every occasion. CORBA interfaces were used to transfer
touchstone between vendors and redeem spent e-coins from broker. The customers
use thin-client vendor interfaces such as JSP implemented HTML to browse vendor
sites. The vendor applications are built using Java Server Pages and Java Beans to
provide plug-in for vendor micro-payment support components.
2.5.4 Payment model comparison
The three payment models we discussed and evaluated are suitable micro-payment
systems in M&E environment. Some of these payment systems are more effective and
efficient than the other in terms of cost cutting, performance (less time to carry out a
transaction) and scalability.
All of the above systems are offline which reduces the communication load on the
broker and speeds up the payment process hence reducing the cost per transaction.
More over some of these systems are non-vendor specific (i.e. the electronic money
can be transferred and used at multiple vendor sites).
20
There are also many micro-payment payment systems that does not provide sufficient
security in terms of detection and prevention of overspending; double spending,
forgery (artificially creating electronic payments) and fraud (posing as another
person/vendor/broker), ease of use and convenience of payment transaction to
customers [1].
We will slightly improve each of the property to make our M&E-NetPay system more
effective and efficient and to survive in the real world for maximal period of time.
Apart from improving the properties of security, privacy/anonymity, validation
(online/offline) and communication load, ease of use and transferability and scalability
we introduce other properties of interoperability and performance in order to reduce
work load on the broker and support vendor applications built on different
technologies and different platform.
Table 2-1 summarizes a comparison of three micro-payment models using the
following eight evaluation criteria [1, 14, 15]:
� Security: The aim of security in the payment protocols is to prevent any party from
cheating the system. For customers, cheating security is specific to the payment
scheme such as double spending coins and creating false coins i.e. forgery during
payment.
� Privacy/Anonymity: Payer and payee should not reveal identities to any third party
or each other. Only the secure broker can identify the participants in a particular
transaction.
� Validation (online/offline) and communication load:
Ability of the payment system to process payment without the need for online
contact with the broker for verifying the payment tokens during transaction.
Online validation requires the broker to validate payment token each time a
transaction is made
� Ease of use: It is the ability of users to use the system easily without
familiarizing with the user interfaces or involved in any type of authentication at
all times.
21
� Transferability:
1. The recipient of a coin can spend that coin with multiple vendors without
having to contact the issuer.
2. The e-coin chain used for micro-payment should be transferable between
vendors to enable users to use the same electronic coin chain to make small
payment to multiple vendors. The e-coins should be flexible enough to make
multiple purchases and should not be specific for payment to just a single
vendor.
� Scalability: The load of any entity must not grow to an unmanageable size. The
load should be distributed among users rather than the broker.
� Performance: The protocol provides high-volume payment support. There should
be no on-line broker authorization server needed by user during payment
processing.
� Interoperability: Interoperability is the ability of the system to be language and
platform independent.
22
Table 2-1 Comparison of M&E micro-payment modelsSystem/ Property MPS CMP NetPay
Security Medium (smart card
device cannot grantee
multiple payment
protection )
Very High (uses
chaotic hash function to
encrypt messages and
services provided to the
user)
Very high (prevents
users from over
spending, prevents
vendors from over
charging, prevent
third-party to forge
e-coins
Privacy/ Anonymity High (The nodes have no
information of the user’s
identity)
Very High (The
vendor has no
information of the
user’s identity. All
information services
between vendor and
user are encrypted)
High (The vendor
has no information
of the user’s
identity)
Validation Off-line (Does not involve
any third party or broker to
pay the nodes in new paths
and does not require the
bank or broker to always
be on-line to verify
payment. )
Off-line (Vendors
does not need contact
broker every time in
order to process
transaction)
Off-line (Vendors
does not need
contact broker every
time in order to
process transaction)
Ease of use Medium (it is a
lightweight payment
scheme. However too
many private, public and
sharing secret keys can
slow the transaction time)
Medium (The use of
double hash chains
and private and secret
keys can slower the
transaction time.)
High (Users need to
spend very less time
in order to buy items
from the vendor
sites)
Transferability Low (Payment chains can
only be transferred between
the nodes in the ad hoc
network. On a new network
the user needs to buy
another payment chain from
the new broker)
High(The same hash
chain can be used on
multiple vendor sites)
High (The e-coins
can freely be
transferred across
multiple vendors for
users to make
multiple purchase)
Scalability Low (Change in route does
not require to contact
broker, however the model
can only support the nodes
Medium (CMP also
requires the vendors to
register with the
broker if they wish to
Medium (no
communication with
broker & low
Volume
23
on in ad hoc network) participate in the
M&E commerce and
the use of too many
keys can be costly in
future.)
transactions.
However CORBA’s
tight coupling
between clients and
servers in mobile
environment makes
it less scalable)
Performance Low (the system uses a lot
of private, public and
sharing keys which can
cause delay in response
time)
Medium (CMP also
requires the vendors to
register with the
broker if they wish to
participate in the
M&E commerce and
use of too many keys
slows the whole
process)
Medium (no
communication with
broker & low
Volume
transactions.
However CORBA’s
tight coupling
between clients and
servers in mobile
environment makes
it weak)
Interoperability Low (This model is only
designed for fixed
network)
Low (does not support
multiple platform and
languages as no
appropriate
middleware is
specified)
Medium(supports
only few platforms
and languages)
24
2.6 Other Web Technologies
Other technologies such as web component technologies and internet component
architecture are used in the development of the micro-payment system. These are .NET
Framework Architecture, Web Services, ASP.NET and Active server pages.
2.6.1 .NET Framework Architecture
.NET framework is a software technology that is focused on connecting information,
people, systems and devices seamlessly. .NET framework 4.0 is the latest release by
Microsoft so far. The high level of software integration has been achieved through the
use of XML based Web Services which enables small and enterprise applications
connect to other applications over Internet. .Net is tiered, modular and hierarchal [39].
.NET languages are top tier and the Common Language Runtime (CLR) is the bottom
tier - works closely with Windows operating system. .NET Framework is a managed
environment [39].The CLR is virtual execution system that provides important
services such as memory management, security and also has a Just-in-Time (JIT)
which converts the Intermediate Language (IL) into native code that can be executed
by the physical machine [40]. Each tier is partitioned into modules which serve their
own distinct purpose. The higher tiers requesting information from lower tiers is called
to be hierarchal. The architecture of the .NET framework is illustrated in Figure 2-5.
The main goal of .NET is interoperability (i.e. language and platform independent).
This is achieved through the use of IL which enables platform independence and
facilitates language interoperability. IL is always JIT compiled [41]. Since the final
code compilation takes place at the runtime, the JIT complier will know exactly what
processer type the program will run on. Hence improved performance is achieved. On
the other hand scripting languages such as Jscript have been upgraded to Jscript.NET
to improve performance.
25
Figure 2-5 An overview of .NET architecture
.NET as a new standard will allow software to run anywhere (i.e. any platform that
offers a browser that understands XML or HTML is a potential .NET client), at
anytime (i.e. Since .NET leverages the Internet, .NET applications such as a Web
service are fully accessible at anytime.), on any platform (i.e. .NET is a multi-language
and multi-platform operating environment), and on devices whether large or small (i.e.
Microsoft adopts HTTP, SMTP, SOAP, XML, and many more standards. This means
that any device that supports these standards can actively participate in a .NET
conversation.) [39].
2.6.2 Web Services
Web Services are an emerging distributed middleware technology that uses SOAP and
simple XML based protocol to allow applications to exchange data across Web. Since
they are based on standards such as HTTP and XML-based protocols including
SOAP and WSDL, Web Services are hardware, programming language, and
26
operating system independent [35]. This concludes that applications written in
different programming language and running on different platforms can seamlessly
exchange data over intranets or the Internet using Web Services.
The benefit of Web Services over other types of distributed computing architectures
includes [36]:
� Interoperability – This is the most important benefit of Web Services. Web
Services typically work outside of the private network, offering developers a
non-proprietary route to their solutions. Such services will have longer life span,
offering better return on investment of developed services. Moreover it allows
developers to use programming language of their choice.
� Usability - Web Services allow the business logic of many different systems to be
exposed over the Web, giving applications the freedom to choose their Web
Services. Instead of re-inventing the wheel for each client, you only need to
include additional application-specific business logic on the client-side, hence
providing the developers to use languages and tools of their choice.
� Reusability – Web Services is the closest thing to zero-coding deployment of
services. Hence Web Service components are reused where applicable in other
services. It also makes it easy to deploy legacy code as a Web Service.
� Deployability – Since Web Services are deployed over standard Internet
technologies, it makes it possible to deploy Web Services over the fire walls to
services running over the internet.
Web Service implementations support different client-side application programmer
interfaces. Client code may work by constructing “call” objects that are dispatched to
the server, or may use a higher level interface that hides the communications level
entirely through the use of client-side stub objects with an operational interface that
imitates that of the server [10].
27
2.6.3 ASP.NET
ASP.NET is a powerful platform for developing web applications [42]. It provides a
tremendous amount of flexibility and support for building any kind of web application.
The high level of frameworks such as Web Forms and Web Services are on very top
level of ASP.NET hierarchy. The lower level of ASP.NET describes how to move
requests from the server to the ASP.Net runtime and through the HTTP pipeline over
the internet.
ASP.NET is a request processing engine. It takes the incoming request from the user
and passes it through its internal pipeline to an end point where developers attach
codes to process the request. ASP.NET runtime can be hosted on a Windows server on
the Internet Information Services (IIS) server. IIS is Microsoft's entry to compete in the
Internet server market that is also addressed by Apache, Sun Microsystems, O'Reilly,
and others [56].This is an evidence of the strength of .NET framework in its ability to
build sophisticated and very performance oriented architectures.
2.6.4 Active Server Pages (ASP)
Active Server Pages [43] are Web pages that contain server-side scripts in addition to
the usual mixture of text and Hypertext Markup Language (HTML) tags. The server
side scripts are special commands on the web pages that are processed before the pages
are sent from the Web server to the Web browser. In the case of Active Server Page all
the server side scripts will be run before it is sent the Web browser. An Active Server
Page looks just like a normal HTML page when it is received by the Web browser.
ASP file can contain any combination of HTML, scripting, and calls to components.
ASP technology is built directly into Microsoft web servers, and is thus supported on
all Microsoft web servers: Windows NT Internet Information Server (IIS) 3, 4 5, 6 &
7, Windows NT Workstation and Windows 95 Personal Web servers. ASP runs as a
service on the web server and is optimized for multiple threads and multiple users.
Thus it is fast and easy to implement. ASPX is an extension of ASP version.
28
2.7 Summary
In this chapter we discussed the back ground information and prior knowledge on
micro-payment system. We have evaluated three other micro-payment systems and
compared them using the eight evaluation criteria. There is a growing need for an
effective and efficient micro-payment technology for high-volume, low-value
transactions for products and services. Current micro-payment systems are not
accepted to such scale. There are several micro-payment technologies in existence but
they still suffer problems like scalability, performance and interoperability. In the next
chapter we briefly discuss our M&E-NetPay system and its advantages over other
micropayment systems.
29
Chapter 3: M&E-NetPay Protocol and System
RequirementsThere are many micro-payment protocols in existence that provides low-value, high
volume transactions and many other improved functionalities. However, some of these
functionalities can be improved further with the implementation of our new M&E-
NetPay protocol. The aim of this protocol is to ease communication processes between
M&E users, vendors and a broker. In previous protocols vendor applications were
needed to be implemented on the same platform and language as the broker application
in order for them to interchange information. This limits the vendors to freely choose
their platform and language. Hence it increases the cost of implementation for existing
vendors by a large amount as the server and the software expenses are relatively high.
This also limits existing vendors to sell their online content by using micropayment
systems. However, M&E-NetPay completely solves the above problem. This is
achieved through the adoption .NET framework (version 4.0) with Web Service
interfaces as middleware to provide a new functionality of interoperability.
Interoperability is one of the main goals of our M&E-NetPay.
In this chapter we will briefly discuss the M&E-NetPay protocol and the interaction of
M&E users, vendors and broker. We have used the Object Oriented Analysis (OOA) to
show the conceptual-level of M&E-NetPay and their data and operations [44]. The
OOA specification deals with three parts: system requirements, use case modelling and
OOA modelling. This chapter also provides a comparison between M&E-NetPay with
other existing micro-payment models.
30
3.1 M&E-NetPay Protocol
M&E-NetPay allows desktop/laptop and mobile users to purchase low value, high
volume goods and services online. This system involves three parties. These are M&E
users (U) (purchases goods and services from the vendor), Vendors (V) (offers
information goods and sells them to the M&E users) and Broker (B) (manage accounts
of M&E users and vendors).We assume that the broker is honest and is trusted by both
the M&E users and the vendors. Assuming that vendors and M&E users are not trusted
and there are third-parties that may try to hack into our system, we used hash functions
to make it secure.
Some of the notations used in the implementation of M&E-NetPay are:
IDa – pseudonymous identity of any party A in the trade community issued by the
broker.
PK-a - A's public key.
SK-a - A's digital signature.
{x}SK-a - x signed by A.
{x}PK-a - x is encrypted by A's public key.
{x}SAK- a - x signed by A using A’s asymmetric key.
There are a number of cryptographic and micropayment terminologies used in the
M&E-NetPay. The description of the above terminologies is given as follows.
3.1.1 One-way Hash Function – the one-way hash function MD5 used in the M&E-
NetPay implementation is used to create digital signatures and payword
chains, which in turn identify and authenticate the sender and verifies e-coins.
More details are provided in section 2.4.3.
3.1.2 Payword Chain – A “payword chain” is generated by using a one way hash
function. Suppose we want to generate a payword chain which contains ten
“paywords”. We need to randomly pick a payword seed W11 and then compute
a payword chain by repeatedly hashing
W10 = h(W11), W9 = h(W10), ……W1 = h(W2), W0 = h(W1)
31
where h( ) is a hash function such as MD5 and W0 is called the root for the
chain. .Net Framework 4.0 library contains MD5CryptoServiceProvider class
which computes the MD5 hash value from the input using implementation
provided cryptographic service provider (CSP). The hash size of
MD5CryptoServiceProvider class is 128bits. The Compute Hash methods of the
MD5CryptoServiceProvider class returns the hash value as an array of 16 bytes.
All MD5 implementation produces a 32-character length hexadecimal-formatted
hash. . This means that every payword Wi is stored as a 32 length string in a
database. A payword chain is used to represent a set of e-coins in the M&E-
NetPay system.
3.1.3 E-coin – An “e-coin” is a unique payword element of length 32 characters
such as W1 or W2, …, or W10 generated by MD5CryptoServiceProvider. We
assume that an e-coin is equal to one cent in money value term. However it
could also be some other value.
3.1.4 E-wallet– An “e-wallet” is used to store e-coins and send e-coins to a vendor
when paying for information goods and services, i.e. it stores one or more
payword chains.
3.1.5 Touchstone – A “touchstone” is a root W0 and is used to verify the paywords
W1, W2, …W10 by taking the hash of the paywords in order W1 first [h(W1)=
W0], then W2 [h(h(W1))= W0], and so on. This is used to verify the e-coins are
“valid” i.e. have not been forged.
3.1.6 Index– Every payword chain has an “index” which is used to indicate the
current amount of e-coins already been spent. For example if you have spent
3cs (W1, W2, W3) to buy an information goods from a payword chain of 10cs
(W1 … W10), now the current index value of the payword chain is 3.
M&E-NetPay differs from the previous protocols in the following aspects: M&E-
NetPay is developed on the .NET platform which uses Web Service interfaces as the
middleware. Web Services carry greater advantages over CORBA when developing
32
mobile applications. Moreover, it also caters for a larger number of M&E users
available via web browsers and mobile phones. M&E-NetPay is language and platform
independence. That is it can be implemented on any platform in any language. In
addition M&E-NetPay has greater scalability and performance than CORBA-based
NetPay as CORBA’s tight coupling between clients and servers in mobile environment
makes it weak
M&E-NetPay protocol uses touchstones that are signed by the broker and an e-coin
index signed by requesting M&E users. The signed touchstone is used by a vendor to
verify the electronic currency – paywords, and signed Index is used to prevent double
spending from M&E users and to resolve disputes between M&E users and vendors.
Figure 3-1 shows M&E-NetPay interactions
33
USER
VENDOR 1
BROKER
EWALLET
VENDOR 2
1. Create Account
BANK
2. Send Login details
3. Buy e-coins (macropayment det, no of e-coins)
6. Generate e-coins
5. Credits account
4. Makemacropayment
7.B
uy it
em(s
)
8. Send (IDe, paywords (m cents), T and I)
9.D
ownl
oad
item
(s)
10. Buy item(s)
11.send (price,host and port)
12. send (IDe,paywords,
V1’s host & port)13. Request T and I
14.sends T and I
15. Download item(s)
16. Request redeem e-coins
17. Credits account 18. Credits
account
Figure 3-1 M&E NetPay interactions
The M&E-NetPay system involves four processes as described below.In our case we
implemented two vendor sites (a ringtone and a wallpaper site) and a broker site.
� Register and buy E-coins from Broker – (1) Before the M&E user (U) can purchase
any item from any of the vendors he/she needs to create an account with B and buy
e-coins. U sends a message, which includes an integer n, the number of paywords in
payword chain requests from B. (2) B debits U’s account and creates a payword
chain (W1, W2, W3,…Wn) to send it to U. The payword chain is created by
repeatedly hashing the recent generated payword commencing with hashing the
root, W0 (W1=h(W0), W2=h(W1), W3=h(W2),…,Wn = h(Wn-1)). Root W0 is used to
verify the validity of paywords. Wn+1 is kept by B to prevent U’s from over
spending and forging the payword chain. U only receives IDe(e-coin ID) and
paywords W1, W2,…,Wn that are encrypted by U’s public key from the broker.
34
� M&E User – Vendor Transaction–(3) When U finds a desired ring tone on V1’s
site, his/her e-wallet sends a message containing IDe, paywords (m cents),
Touchstone (T) and Index={IDe,i} SK-C to V1. (4) V1 verifies the paywords. If the
paywords are valid it is saved to V1’s database and the ringtone is downloaded on to
U’s computer or mobile phone. U can perform multiple transactions with one
payword chain until the payword chain is fully spent. If no e-coins are left then U
will be directed to B’s site to buy more e-coins.
� Payword reallocation between Vendors – (5) Now U wishes to download wallpaper
from V2 and sends a purchase request. V2 sends the price, host and port to the e-
wallet. The e-wallet compares the host and port with the previous host and port. If
different, the e-wallet sends a message = {IDe, paywords, V1’s host and port} to V2.
V2 request the current e-coin index and T from V1 (U’s previous vendor) by sending
IDe. V1 sends a signed transmission message containing Index = {IDv1,i}SK-v1and T
to V2 where I is the index of the last payword. V2 verifies the paywords using the
index and T. If paywords are valid the wallpaper is downloaded to U’s computer or
mobile phone. This transaction does not involves B as information is transferred
between V1 and V2 decreasing the communication load on B. Moreover the use of
current Index of paywords prevents the U’s from double spending when purchasing
goods and services online.
� Offline redeem request – At the end of each business day (or other suitable period)
for each payment received the vendors need to send all paywords they received
from the M&E users to B and redeem them for money. The paywords should be
accompanied by the e-coin ID (IDe). The broker verifies each payword from the
vendor by performing hashes on it. If the paywords are valid, the broker deposits the
amount to respective vendors’ accounts, and then sends an acknowledgement
message.
35
3.2 Payment System Comparison
In section 2.5.5, we evaluated the three micro-payment protocols using the evaluation
criteria. We will evaluate and compare the M&E-NetPay protocol with three micro-
payment models that is already being discussed.
Table 3-1a Comparison of M&E-NetPay with other micro-payment modelsSystem/ Property MPS CMP NetPay M&E NetPay
Security Medium (smart
card device
cannot grantee
multiple
payment
protection )
Very High (uses
chaotic hash
function to
encrypt messages
and services
provided to the
user)
Very high
(prevents users
from over
spending,
prevents vendors
from over
charging, prevent
third-party to
forge e-coins
Very High
(prevents
M&E users
from over
spending,
prevents
vendors from
over charging,
prevent third-
party to forge
e-coins
Privacy/ Anonymity High (The nodes
have no
information of
the user’s
identity)
Very High (The
vendor has no
information of
the user’s
identity. All
information
services between
vendor and user
are encrypted)
High (The
vendor has no
information of
the user’s
identity)
High (The
vendor has no
information of
the M&E
user’s identity)
Validation Off-line (Does
not involve any
third party or
broker to pay the
nodes in new
paths and does
not require the
bank or broker to
always be on-
line to verify
payment. )
Off-line
(Vendors does
not need contact
broker every
time in order to
process
transaction)
Off-line
(Vendors does
not need contact
broker every
time in order to
process
transaction)
Off-line
(Vendors does
not need
broker’s
service on
each item
purchased)
36
Table 3-1b Comparison of M&E-NetPay with other micro-payment modelsSystem/
Property
MPS CMP NetPay M&E NetPay
Ease of use Medium (it is a
lightweight payment
scheme. However
too many private,
public and sharing
secret keys can slow
the transaction time)
Medium (The
use of double
hash chains and
private and
secret keys can
slower the
transaction
time.)
High (Users
need to spend
very less time in
order to buy
items from the
vendor sites)
High (Provides
simple interfaces
which are easy to
use. Web Service
uses SOAP and
simple XML
based protocol
that makes
payment process
faster
Transferability Low (Payment
chains can only be
transferred between
the nodes in the ad
hoc network. On a
new network the
user needs to buy
another payment
chain from the new
broker)
High(The same
hash chain can
be used on
multiple vendor
sites)
High (The e-
coins can freely
be transferred
across multiple
vendors for users
to make multiple
purchase)
Very High (The
e-coins can
freely be
transferred
across multiple
vendors for
M&E users to
make multiple
purchase. Web
Service
interfaces
provide extra
simplicity on
transferring e-
coins between
vendors)
37
Table 3-1c Comparison of M&E-NetPay with other micro-payment modelsSystem/
Property
MPS CMP NetPay M&E netPay
Scalability Low (Change
in route does
not require to
contact broker,
however the
model can
only support
the nodes on in
ad hoc
network)
Medium (CMP
also requires the
vendors to register
with the broker if
they wish to
participate in the
M&E commerce
and the use of too
many keys can be
costly in future.)
Medium (no or
less
communication
with broker &
low Volume
transactions.
However
CORBA’s tight
coupling between
clients and
servers in mobile
environment
makes it less
scalable)
High (no or less
communication with
broker and low
volume information
transfer. .NET
applications such as
a Web service are
fully accessible at
anytime on any
platform and can
support any number
of M&E users)
Performance Low (the
system uses a
lot of private,
public and
sharing keys
which can
cause delay in
response time)
Medium (CMP
also requires the
vendors to register
with the broker if
they wish to
participate in the
M&E commerce
and use of too
many keys slows
the whole
process)
Medium (no
communication
with broker &
low Volume
transactions.
However
CORBA’s tight
coupling between
clients and
servers in mobile
environment
makes it weak)
High (no less
communication with
broker and low
volume information
transfer. .NET
applications such as
a Web service are
fully accessible at
anytime on any
platform and can
support any number
of M&E users)
Interoperability Low (This
model is only
designed for
fixed network)
Low (does not
support multiple
platform and
languages as no
appropriate
middleware is
specified)
Medium(support
s only few
platforms and
languages)
Very High (supports
all platforms and
languages)
38
The above evaluation shows that the M&E-NetPay system has greater advantages over
other micro-payment systems. The M&E-NetPay is an offline fully distributed system,
most suitable for micro-payments over the World Wide Web (WWW). M&E-NetPay
has very high security features as it uses one-way hash functions to generate paywords
which prevent M&E users and vendors from over spending and forging paywords
from a payword chain. Since only the broker knows the mapping between the
pseudonyms (IDc) and the true identity of a M&E user, M&E user’s privacy is
protected. In terms of transferability the e-coins can be transferred freely between
vendors’ for multiple purchases. Transferability is an important criterion which
improves anonymity and performance of micropayment systems.
The M&E-NetPay system has a greater scalability and performance features as it
supports rapidly growing number of M&E users. In comparison with NetPay, it has
lesser ability since CORBA’s tight coupling between clients and servers. In section
2.5.3, the NetPay uses CORBA middleware interfaces to support a couple of
programming languages (e.g. Java and C++) and platforms (e.g. Windows, Linux).
However vendor systems have to be “hard-coded” with CORBA by communicating
with NetPay broker to exchange messages. . The M&E-NetPay is the solution to the
above problem as it can support any language and any platform. Hence it has a very
high rating of interoperability.
3.3 M&E User Requirements and Use Cases
The OOA model is composed of graphical or text-based representations that define
class attributes, relationships, behaviours, and inter-class communication [46]. OOA
begins with use cases (scenario-based description) of how actors (people, machines
and systems) in the problem space intermingle with the product. OOA task includes
basic M&E user requirements, identifying of classes, specifying of class hierarchy,
representing object-to-object relationships and modelling object behaviour.
Requirement analysis is the process of understanding M&E users’ needs and
expectations from a proposed system. There are three types of activities involved in
the requirements phase. These are eliciting requirements – to determine the possible
39
requirements of a client, analysing documents – to determine the clearness of the
requirements and recording requirements.
The M&E-NetPay system involves four parties which are M&E users, vendors, broker
and bank macro-payment system. The M&E user is issued a unique e-coin id and a
payword chain every time he/she buys e-coins from the broker. The e-coins are stored
in the M&E user’s e-wallet.
The M&E user now logs onto the vendor’s site using the e-coin id and password. In
our case two vendor sites are implemented, a ringtone and a wallpaper site. The M&E
user browses through the entire site and selects the desired ringtone or wallpaper.
There is a small cost assigned to each ringtone and wallpaper depending on its demand
and rating. When the M&E user clicks on the download button on the ringtone site, the
ringtone-vendor verifies that the e-coins provided by the M&E user are valid by using
the “touchstone” obtained once only from the broker. If the payment is valid (coin is
verified and sufficient credit remains), the broker debits the M&E user’s account by
the cost of the ringtone (e.g. if the M&E user is downloading a ring tone costing 10c
then the M&E user’s account is debited by 10c) and the ringtone is downloaded onto
the M&E user’s mobile or PC.
After purchasing a particular ringtone, the M&E user may browse for other ringtones.
The M&E user’s e-wallet is saved on the last vendor’s site which he/she visited. When
the M&E user logs on to the next vendor’s site (wallpaper site), the vendor requests the
current e-coin touchstone and index information from the previous vendor (ringtone
site).
The wallpaper-vendor establishes connection to ringtone-vendor via Web Services
interfaces and the M&E user’s e-wallet is transferred from the ringtone-vendor to the
wallpaper-vendor.
When the previous vendor system is “down”, the new vendor contacts the broker to get the
e-coin touchstone and the current index. If the M&E user runs out of e-coins he/she is
directed to the broker’s site to buy more e-coins. At the end of the day all the vendors
get the money values from the broker in return of e-coins.
40
From the above description several stakeholders of the M&E-NetPay system are
identified. Thus we present main use case scenarios of the system. The following
sections illustrate functional and non-functional requirements for the system.
3.3.1 Use Case Diagram
A use case is a set of scenarios that describes an interaction between the M&E user and
a system (e.g. M&E-NetPay system). A use case diagram displays the relationship
among actors (M&E users, vendors, broker and bank) and use cases. The two main
components of a use case diagram are use cases and actors [47].
The primary goal of a use case analysis are: designing a system from the M&E user’s
perspective, communicating system behavior in the M&E user’s terms, and specifying
all externally visible behaviors. In this section we focus on use case modelling to
determine M&E-NetPay micro-payment system’s requirements. Thus we get
functional requirements of M&E-NetPay.
In the M&E-NetPay system the actors are: M&E users, macro-payment system (e.g.
bank), vendors (e.g. ringtone site, wallpaper site) and broker. The broker is
responsible for the registration of M&E users, generation of e-coins and crediting the
vendor’s account and debiting the M&E user’s account via a macro-payment system.
The broker is assumed to be honest and is trusted by both the M&E users and the
vendors.
Figure 3-2 shows basic M&E-NetPay use case view. It shows that the M&E user can
register and purchase e-coins (using macro-payment such as credit card) from the
broker site. The M&E user buys e-coins from the broker which is stored in his/her e-
wallet. When purchasing items the M&E user sends the e-coins from his/her e-wallet
to the vendor, V1. If this is the M&E user’s fist vendor (V1), V1 communicates with the
broker to obtain validating touchstone for the e-coins. V1 verifies the e-coins and
allows the M&E user to download the selected item. At the end of the day, V1 can
redeem e-coins with broker for real money.
41
Figure 3-2 Basic M&E NetPay interactions
Each e-coin encodes a “payword chain” which utilizes a fast hashing function to
provide the next valid coin in the chain each time a coin is spent. When the M&E user
chooses to purchase items from another vendor (V2), V2 obtains touchstone and index
from previous vendor (V1). If V1 is offline then V2 contacts the broker for the
touchstone and the index. If the M&E user runs out of e-coins he/she needs to buy
more from the broker. The transfer of e-coins is done using public key encryption to
make it more secure. An index is used to indicate the amount of e-coins spent so far
which prevents M&E users from double spending and vendors from over debiting. The
M&E-NetPay system prevents the M&E users from revealing its identity to any vendor
or third party. Only the broker can identify the participants in a particular transaction.
3.3.2 Use Case Descriptions
We describe the use cases for M&E user registration, buy e-coins, debit e-coins and
redeem e-coins in this subsection. The tables 3-2 to 3-5 describe the event flow of the
use cases and the screen dumps. Figure 3-3 to 3-5 show the corresponding interfaces of
the use cases.
42
Table 3-2 Register Use Case
User Case Name Register
Description: Used by M&E-users to register with broker
Event Flows:
M&E users logs in to broker’s home page and selects
“Register”. M&E user fills in the registration
information which includes M&E user name,
password, email address, and credit card details to open
an account as shown in Figure 3-3. The M&E user then
clicks on register button. If the credit card information
is not valid, go to step 3.
Broker generates a customer ID and creates an account
for the M&E user.
Invalid credit card information – error message
displayed. Go to 1.
Related Actors/Use Cases: Used by M&E user actor
Special Conditions:
Figure 3-3 Example Mobile user registration
43
Table 3-3 Buy E-coins Use Case
Use Case Name: Buy E-coins
Description: Used by M&E users to buy E-coins with broker system
Event Flows:
1. M&E user logs onto the broker’s site using the customer
id provided as shown in Figure 3-4 (1).
2. The system displays the balance. If the M&E-user wishes
to purchase more e-coin, then he/she clicks on “Buy” and
enters the amount of e-coins in the textbox provided as
shown in Figure 3-4 (2).
3. Broker debits money from the credit card or the bank
account M&E user supplied via a macro-payment
transaction. If the account does not exist, go to 5 else go
to 4. The e-coin balance is shown in Figure 3-4 (3).
4. Broker generates e-coin payword chain which includes e-
coin ID, root, seed, paywords, amount and sends to the
M&E user’s e-wallet.
5. Incorrect credit card information – error message
displayed. Go to 1.
Related Actors/Use Cases: Used by M&E user actor
Special Conditions:
44
Figure 3-4 Example of mobile user buying e-coins
(1)
(2)
(3)
45
Table 3-4 Debit E-coins Use Case
Use Case Name: Debit E-coin
Description: Used by M&E-users to buy ring tones and wallpapers from
vendors.
Event Flows:
M&E-user browsers through the vendor site and select the
desired ring tone or wallpaper. The M&E user clicks on
download button to download it to his/her computer or mobile
as shown in Figure 3-5 (1)
M&E user sends the e-coins from his/her e-wallet and the
vendor system verifies the e-coins by using touchstone. If the
e-coins are invalid or not sufficient e-coins left, go to 4.
If the e-coin verification is successful, the file is downloaded to
the M&E user’s computer or mobile. Figure 3-5 (2) shows the
balance after the purchase has been made.
Send message to M&E user about the status and cancel
download.
Related Actors/Use Cases: Used by M&E user actor
Special Conditions:
46
Figure 3-5 Mobile user downloading ring tone from the vendor site.
Table 3-5 Redeem E-coins Use Case
Use Case Name: Redeem E-coins
Description: Used by vendors to redeem e-coins from broker.
Event Flows:
To redeem e-coin the vendor selects “Redeem”. The M&E-
NetPay application automatically sorts all the payments
received from all M&E-users based on the e-coin ID and
sends them to the broker.
The broker redeems the total e-coins with the money value
and credits the vendor’s account.
Related Actors/Use Cases: Used by vendor actor
Special Conditions:
(1)
(2)
47
3.4 Non-functional Requirements
Non-functional requirements are requirements that specify criteria that can be used to
judge the operation of a system, rather than explicit behaviors [48]. They are the
constraints or quality of service requirements on system operations. In this system,
non-functional requirements include:
3.4.1 Performance Characteristics
� The system response time should be less than 5 seconds. There can be variable
timings for downloading files of different sizes. The system must avoid the
central bottleneck.
� The system should be distributed along multiple servers so that the workload is
shared.
� Any transaction process should include very small number of steps.
� The system should support at least 5,000 M&E users simultaneously.
3.4.2 Quality Issues
� Online access to the broker system is not very critical, but downtime should be
limited to less than an hour.
� The system should indicate this by some sort of visual display in case of delays
or error.
� Power failure needs to be handled by UPS for the broker’s main server machine
and database.
3.4.3 Security and Integrity Issues
� Only broker can generate e-coins and change account data of the M&E users and
vendors.
� The web server should be very secured carefully covering any known and
popular security holes and exploitation points.
� The local unit running the web site is responsible for the security, and should take
care to ensure that it doesn’t become a potential point of entry into the broker
system.
� Backups should be done on a daily basis.
48
3.4.4 Documentation
� The system must contain help documentation for M&E users to overcome any
problems encountered.
3.4.5 M&E User interface
� M&E users should be prevented from making errors using pertinent reasoning of
messages.
� The system should be easy to learn.
� Clear titles, heading and subheading should be on each page
3.5 M&E-NetPay OOA Modelling
OOA is a collection of like-minded requirements modelling and analysis techniques
for software systems proposed in late 80’s. The Basic aim of OOA is to streamline
software development by making objects, classes, methods and like the atomic units
out of which one builds requirements, designs and implementations [49].The static
M&E-NetPay system structure will be described using a class diagram. Sequence
diagrams will be used to describe dynamic behaviors among the objects of M&E-
NetPay system.
3.5.1 Class Modelling
A class model is comprised of one or more class diagrams and the supporting
specifications that describe model elements including classes of the system, their
interrelationships (including inheritance, aggregation, and association), and the
operations and attributes of the classes. Class diagrams are used for variety of
purposes, including both conceptual/domain modeling and detailed design modeling
[50].
The class diagram shows three distinct areas [51]:
� The class name (and stereotype if applied).
� The class attribute area (i.e. internal data elements)
� The behavior – both private and public
Attributes and methods may be marked as [51]:
49
� Private, indicating they are not visible to callers outside the class
� Protected, they are only visible to children of the class
� Public, they are visible to all
Based on the use cases and scenarios discussed in Section 3.3, the OOA-level class
diagram for M&E-NetPay micro-payment system was built, which is shown in Figure
3-6.
Figure 3-6 M&E-NetPay micro-payment system class diagram
50
� Customer: This object encapsulates all the information of M&E user’s personal
and account information. The M&E user needs to register an account with the
broker if they wish to purchase any item. This object includes customer_id, name,
email address, password and credit card details. It also provides a set of business
methods to access the customer information.
� E-wallet: This object stores e-coins’ information which includes ecoin_id,
paywords, amount (the number of e-coins spent by the M&E user), host and host
address and the information access methods.
� Broker: This object sums up all the information of the broker account. Broker
needs to redeem all the e-coins received from vendors in money value and credit
the vendors’ account. This object includes broker_id, name, phone number, e-mail
address, and balance.
� E-coins: This object records bought e-coins information which includes ecoin_id,
root, seed, paywords, amount (the number of e-coins the M&E user bought) and
the information access methods.
� TandI: This object records the touchstone and index information which are used to
verify e-coins by vendors.
� Wallpaper: This object keeps all wallpapers record which include wallpaper_id,
title, category, movie, date posted, price, description and wallpaperURL. It also
specifies a set of business methods to access its information.
� Ringtone: This object keeps all ringtones record which include ringtone_id, title,
category, movie, date posted, price, description and ringtoneURL. It also specifies
a set of business methods to access this information.
� Redeem: This object contains all the information of e-coin payments by M&E
users including redeem_id, ecoin_id, index, price, paywords and chain. It also
provides the functions for adding, finding, and deleting payment information.
51
3.5.2 Sequence Modelling
As class modelling is used for static structure, sequence modelling is used for dynamic,
a structure which focuses in identifying the behavior within the system. Below is a
description of the interaction among the objects of M&E-NetPay with four UML
sequence diagrams.
3.5.2.1 Register and Buy E-coins
The sequence diagram in figure 3-7 shows the M&E user registers with the broker and
buys e-coins using the credit card.
� The M&E user clicks on “Create Account” link on the broker’s site.
� The broker application opens a new page requesting the M&E user to enter account
details.
� The M&E user clicks on the link “Create” and the M&E user’s account is created.
The broker issues the customer id to the M&E user.
� The M&E user clicks on “Buy” button on the broker’s site.
� The broker verifies the credit card details and debits the M&E user’s account.
� The broker system then generates a unique E-coin ID and payword chain and
records the e-coin data.
� The e-wallet is then sent to the broker and the broker displays the balance to the
M&E user.
52
M&E-User Broker E-wallet Ecoin Macro-payment
1. Create Account
2. Enter account Details
3. create
4. Registrationsuccessful
5. Buy E-coins
6. Enter Amount
7. Buy
8. VerifyCreditCard()
9. Card Verified
10. DebitCustomerAccount()
11 generateEcoins()
12. sendEwallet()
13. DisplayBalance()
Figure 3-7 Register and buy E-coins sequence diagram
3.5.2.2 Purchase from first vendor (Ringtone site)
Figure 3-8 shows the sequence diagram for M&E user who wishes to purchase ring
tone from vendor (V1).
� The M&E user searches for the desired ring tone by providing ring tone details.
The vendor system displays the possible list to the user.
� The M&E user selects the desired ring tone and the vendor system checks if there
are sufficient e-coins in the e-wallet.
53
� If there are not enough e-coins then the M&E user is directed to the broker’s site to
buy more e-coins.
� If the e-coins are enough, V1 gets the touchstone and index and verifies the e-coins
� If the e-coins are not verified the transaction is terminated.
� If the e-coins are valid, V1 debits the e-coins and generates a unique redeem ID and
records the redeem data.
� V1 downloads the ring tone file to the M&E user’s computer or mobile.
Figure 3-8 Buy ring tone with vendor (V1) sequence diagram
54
3.5.2.3 Purchase from another vendor (Wallpaper site)
Figure 3-9 shows the sequence diagram for M&E user who wishes to purchase
wallpaper from vendor (V2).
� The M&E user searches for the desired wallpaper file by providing wallpaper
details. The vendor system displays the possible list to the user.
� The M&E user selects the desired wallpaper and the vendor system checks if there
are sufficient e-coins left in the e-wallet.
� If there are not enough e-coins, the M&E user is directed to the broker’s site to buy
more e-coins.
� If V2 has not obtained T and I, V2 gets the touchstone and index from V1 and
verifies the e-coins.
� If V1 is offline V2 requests the broker for T and I.
� If the e-coins are not verified the transaction is terminated.
� If the e-coins are valid, V2 debits the e-coins and generates a unique redeem ID and
records the redeem data.
� V2 downloads the ring tone file to the M&E user’s computer or mobile.
55
Figure 3-9 Buy wallpaper with vendor (V2) sequence diagram
3.5.2.4 Redeem E-coins
Figure 3-10 shows the sequence diagram for vendor actor who wants to redeem e-
coins with the broker.
� Vendor logs in to the system and selects “Redeem”, the system aggregates all
redeem data and sends to broker.
� Broker system gets touchstone of the e-coins from the e-coin object and verifies
the redeem data.
� If all redeem data are valid, the broker system generates and sends updated balance
to the vendor.
56
Figure 3-10 Redeem E-coins with broker sequence diagram
57
3.6 Summary
M&E-NetPay system has greater capabilities than other micro-payment systems. It is
cheap, secure, widely available and debit-based protocol. M&E-NetPay stands out in
scalability, performance, anonymity and interoperability while other micro-payment
systems lack some or most of these. This protocol prevents double-spending and
forging of e-coins by vendors, M&E users and other third parties.
M&E-NetPay is cost effective since it uses one-way hash functions per purchase rather
than public key operations. The major advantage of M&E-NetPay protocol is its
interoperability property. M&E-NetPay is compatible with any language and platform.
We discussed the M&E user requirements of M&E-NetPay to determine its overall
functionality. Use case diagrams and descriptions were used to gather functional
requirements on M&E-NetPay system. To determine the objects and its static
relationship UML class diagrams were used. UML sequence diagrams were used to
show the dynamic interaction of the system. Moreover, non-functional specification
was used to describe various constraints on systems’ operation. We will use the
information collected from the OOA phase to discuss the Object Oriented Design
(OOD) phase in the next chapter.
58
Chapter 4: M&E-NetPay Architecture and
DesignWe describe the software architecture (the machines, programs, etc. that makes up the
system) of our M&E-NetPay system and the appropriate implementation tools,
languages, APIs used during the implementation of our system. We have split our
OOA to determine the Object Oriented Design (OOD) classes that make up our
programs that comprise the architecture we have designed [45]. An OOD process
involves designing the object classes and the relationships between these classes
[52].The design of M&E-NetPay application including broker and vendor systems are
discussed in this chapter. Sequences of operations of M&E-NetPay application
software with examples are also presented.
4.1 M&E-NetPay Software Architecture
We have developed a software architecture for implementing M&E NetPay micro-
payment systems. These systems are thin-client n-tier web & mobile based
applications. The software architecture is entirely designed for Microsoft.NET
applications. The use of Web Services has made our implementation much easier by
enabling inter-connection between remote sites. The M&E-NetPay micropayment
transactions involve three key parties: a Broker Server, a Vendor Server, and a M&E
user browser [3].
The Broker server database holds all registered M&E users’ account information and
transaction history. The e-wallet of a M&E user resides on the broker’s database until
the M&E user logs on to any vendor sites using the given e-coin id. Upon logging in
the e-wallet of the M&E user is transferred to the visiting vendor. The broker server
also helps the vendors verify e-coins when the M&E users try to purchase any item
from their sites. The broker also provides functionalities to vendors to redeem e-coins
spent on their site and request touchstones. These functionalities are provided by the
broker’s “BrokerVendor” Web Service as shown in Figure 4-1. This Web Service is
only available to the vendors for accessing certain information from the broker’s
database.
59
The M&E users can access the broker site using their mobile phones or PCs as long as
they have internet access. The mobile users use the Wireless Markup Language
(WML) based web browser in their mobile phones to access the Broker Mobile
application which has got small interfaces suitable to fit on mobile phone’s screen
whereas the Internet users can access Broker Web application through the web
browser. The M&E user inputs are assigned to the broker data entities on the client
end and are retrieved by the data layers when needed. The mobile and web applications
references the same Web Services hosted on the broker’s application server. The
broker Web Services passes information in a XML-based message to the business
logic layer. The business logic layer implements all the business rules for the
application. The business logic layer passes the information to the data adapter layer -
the broker database and executes the necessary queries. The Data Adapters are used to
exchange data between a data source and a dataset [53]. In our applications, it means
reading data from a database into an entity or entity collection, and then writing altered
data from an entity back to the database. The entire process is shown in Figure 4-1.
60
Figure 4-1 Basic Software Application Architecture
Similarly, vendor sites also provide interfaces to both mobile and internet users. The
vendor sites allow M&E users to browse through their entire website and purchase any
items they wish to buy. In our case when the M&E user logs in to the Ringtone site,
the Ringtone vendor requests for the e-wallet from the broker. This facility is available
on the “BrokerVendor” Web Service provided by the broker. If the Ringtone vendor
finds that the M&E user’s e-wallet resides on another vendor site, it then requests the
e-wallet from that vendor which contains the e-coin indexes and touchstones. All
vendors have a Web Service named “OutsideVendor” which allows the other vendors
to retrieve their logged in M&E user’s e-wallet. The e-wallet is then stored on the
current vendor’s site. When any item is purchased by the M&E user, his/her e-wallet is
debited (i.e. the e-coins in the e-wallet is decremented).
61
4.2 M&E-NetPay Software Deployment Architecture
After evaluating the OOA specifications (use cases, sequence diagrams and non-
functional specification), we are now in a better position to determine the deployment
architecture of our M&E-NetPay application. Keeping in mind of some general
qualities of performance, security, availability and serviceability we designed the
M&E-NetPay application’s deployment architecture as shown in Figure 4-2.
Figure 4-2 Basic M&E-NetPay Deployment Architecture
The M&E-NetPay is a thin-client n-tier application which is distributed along multiple
servers to share workload. The broker and vendor web/mobile Applications are
deployed on their respective Web servers and likewise their Web Services are
published on their respective Application servers. The broker and vendors have their
own Database servers to store required information. The core advantage of this
approach is that any person logging in the broker or vendor system can only have
access to Web servers. From there onwards the information is transferred through
secure channel in a XML message which can not be intercepted by any third party.
Moreover, the Web Services on Application servers is only available on requests from
mobile/web applications on Web servers. No third party has any possibilities of
62
logging directly or indirectly on to the Application Servers. In addition Application
Servers will not be accessible from outside the network (i.e. via internet).
The above architecture allows M&E-NetPay vendors and the broker to use certain
Web Service interfaces of the other party in order to exchange M&E users’
information. The M&E-NetPay is easily maintainable and serviceable as any changes
will only need part of the application to be configured. For example if the Ringtone
vendor wishes to change the display of its site then only the web/mobile application on
the Ringtone vendor’s Web Server will be re-configured
4.3 M&E-NetPay Object Oriented Design
We present a detailed OO design from the OOA specification discussed in the previous
chapter and the software architecture of M&E-NetPay discussed in section 4.1 and 4.2.
Object-oriented design is concerned with developing an object-oriented model of a
software system to implement the identified requirements [54]. We discuss the static
and dynamic OOD in this section.
4.3.1 Static System Design
OOD draws upon class definitions that are derived from the OOA. An OO design
model encompasses software architecture, user interface description, data management
components, task management and detailed description of each class to be used in the
system [55]. OOD of M&E-NetPay e-wallet, broker and vendors are discussed in the
following sections
4.3.1.1 M&E-NetPay E-wallet
The M&E-NetPay e-wallet is a server-side e-wallet that is created by broker and it
resides on the last vendor the M&E user visited. That is the M&E user’s e-wallet is
transferred across the vendors depending on which vendors the M&E user is buying
items from. When the M&E user makes a purchase from vendor (V1), V1 request the
Touchstone and Index (T&I) from the M&E user’s previous vendor. If V1 is the first
vendor then it has to contact the broker for T&I. The vendors use T&I to verify e-
coins.
63
To achieve our goals we designed the broker and vendors’ application on .NET
Framework and to use Web Service interfaces as the middleware to communicate with
each other to get T&I. In order to get T&I from another vendor, the current vendor
sends a XML based message via Web Services.
The M&E user buys e-coins from broker using Web Service interfaces. The broker
connects to the Bank to debit the M&E user’s account and generates and stores e-coins
in the M&E user’s e-wallet. When the M&E user wants to buy an item, the vendor
server communicates with broker or the previous vendor via Web Services to obtain
T&I to verify e-coins. Figure 4-3 shows the M&E E-wallet design feature.
64
Figure 4-3 M&E-NetPay e-wallet design feature
4.3.1.2 M&E-NetPay
The M&E-NetPay broker system which has a multi-tier web-based architecture built
on top of the .NET framework 4.0 is presented as follows:
� Client tier (HTTP Browser): The browser communicates with the Web server
which runs the ASPX web pages to register M&E users and buy e-coins.
65
� Web tier (Broker Web Server and ASPXs): The broker Web application is
deployed on the Web Server’s Microsoft's Internet Information Server (IIS). M&E
users connect to the web server by typing the broker’s Uniform Resource Locator
(URL) address in the HTTP browser. If the broker is online its homepage is
displayed to the M&E user. When the user makes a request, the ASPXs forward it
to the Application Server (Web Services) and when the Application Server makes a
response, the Web server forwards it over the HTTP browser and the content is
displayed to the M&E user. The IIS is designed to support multiple uses
simultaneously.
� Application Server tier (WEB Services): The broker Application Server host
broker’s Web Service interfaces which is implemented in C Sharp (#) language on
.NET framework 4.0 and uses SOAP and simple XML based protocol to allow
applications to exchange data across the Web. Web Services are also implemented
over the IIS. The Broker Application server is not accessible to anyone via internet
since it is hosted internally. Only some of broker’s Web Services are available to
M&E-vendor Web applications in order to get T&I and redeem e-coins.
� Database Server tier: For data storage we implemented the database on Microsoft
Standard Query Language (MSSQL) 2005. SQL Server 2005 introduces several
high availability solutions to improve the availability of servers and databases.
These solutions mask the effect of hardware or software failure and maintain the
availability of applications so that M&E users perceive a minimum of downtime
[57].
Similarly, the Vendor systems have multi-tier web-based architecture built on top of
the .NET framework 4.0. Vendor systems have the same architecture as broker system
just the functionalities they provide differ.
4.3.1.3 Broker OOD class diagram
The broker system is divided into registration, buying e-coin and redeeming e-coins.
The following are the class diagrams of the above divisions.
66
4.3.1.3.1 Register Objects
Register objects is a four tier architecture which is responsible for registration of new
M&E users with the broker system as shown in Figure 4-4.
Figure 4-4 Register class diagram
Register ASPX – deals with requests from Web/Mobile client. The requests
incorporate receiving M&E user information; sending register/cancel requests to
register C Sharp (#) code behind which forwards the request to the Application Server.
Register User C# – is the C# code behind the ASPX pages. It takes the registration
inputs via ASPX, validates it and forwards the request to the Application server for
further process.
67
RegisterWebChannel – holds the Web Services Interfaces and is only available to
authenticated M&E users. It uses XML-based messages to transfer data. It receives the
registration request from the Web application and calls the business component’s
registerUser method.
RegisterBusinessComponent – defines the register user business rules and calls the
data adapter method.
RegisterDataAdapter – opens the SQL connection and passes the user information to
the query (stored procedure) “prc_registerUser” located in SQL 2005 database server.
The broker SQL server executes the stored procedure and upon successful execution it
returns the user ID via the Register data adapter.
CustomerEntity – holds the account details for the M&E users.
SQLConnection – is used by manager objects to connect to DB.
68
4.3.1.3.2 Buy E-coin Objects
Buy e-coins deals with the registered M&E users purchasing e-coins from broker. The
class diagram is shown in Figure 4-5.
Figure 4-5 Buy e-coin class diagram
BuyEcoins – is an interface which provides functions for M&E users to purchase e-
coins using credit card. The functions include debiting amount from M&E user’s credit
card, generating e-coin, and saving to M&E user’s e-wallet.
69
EcoinWebChannel – It receives the “buyEcoin” XML request with parameter n-
number of e-coins, from the broker Web application and calls the business
component’s “buyEcoin” method.
EcoinDataAdapter – opens the SQL connection and call for execution of “buyEcoin”
query. The generated e-coins and its details are inserted to the M&E user’s e-wallet.
The generated e-coin ID is returned to the application via data adapter.
EcoinData – contains all attributes of an e-coin.
70
4.3.1.3.3 Redeem e-coins Objects
The M&E-vendors communicates with the broker’s Web Service interface to redeem
e-coins as shown in Figure 4-6.
Figure 4-6 Redeem E-coin class diagram
Redeem – this interface provides functions for M&E-vendors to redeem spent e-coins.
The functions include receiving redeem information, verifying spent e-coins, updating
vendor account balances, sending balance to the vendors and storing transaction
history.
71
RedeemWebChannel – The Web server vendor and the broker are at remote locations
to each other but connection is possible via Web Service interfaces.
RedeemDataAdapter – calls the execution of ‘redeemEcoins’ query. This query
validates the spent e-coins, updates the transaction history table and returns the new
account balance.
TransactionHistoryEntity – contains all redeem messages.
EcoinEntity – contains all attributes of an e-coin
4.3.1.4 M&E-Vendor OOD diagram
M&E-vendors allows M&E-users to download files. The following shows the object
class diagram for transfer of T&I, searching of wallpaper file, wallpaper download and
redeem spending.
4.3.1.4.1 Transfer T&I Objects
Transfer T&I provide a Web Service interface with which the M&E-vendors’ server
communicates to get T&I as shown in Figure 4-7.
72
Figure 4-7 Transfer Touchstone and Index class diagram
OutsideVendorChannel – is an interface which provides functions for the other
M&E-vendors to request T&I information including e-coin ID, touchstone, index of
the payword chain and left e-cons. Figure 4-7 shows the current vendor making a
request with the previous vendor to retrieve T&I and e-coins. The functions contain
transferring e-coin ID, touchstone, index and e-coins from one vendor to another
vendor.
73
4.3.1.4.2 Search Wallpaper Objects
Figure 4-8 Search Wallpaper class diagram
Search Wallpaper ASPX – allows the M&E-users to search for desired wallpaper
using the search criteria. Wallpapers can be searched by title, description, category,
movie, and date posted.
WallpaperWebChannel – is a Web Service interface that provides wallpaper search
functionalities to M&E-users.
74
4.3.1.4.3 Download Wallpaper
Wallpaper Vendor allows M&E users to download wallpapers for which they have
paid for. When the M&E user clicks on the “Download” button the Wallpaper
application uses the OtherVendor Web Service interface to request T&I from the M&E
user’s previous vendor. If the previous vendor is down or if the wallpaper vendor is the
first vendor then it connects to broker via “BrokerVendor” Web Service interface to
get T&I.
When the e-coins are verified the WallpaperWebChannel uses Wallpaper Web Service
interface to get the selected wallpaper details. Wallpaper details contain
“wallpaperURL” which specifies the location of that wallpaper. The download
interface uses the wallpaper location to retrieve the wallpaper from the Wallpaper
folder and downloads it onto the M&E user’s computer or mobile. Figure 4-9
illustrates the download wallpaper class objects.
75
Figure 4-9 Download Wallpaper class diagram
4.3.1.4.4 Redeem Spending
The vendor web server connects to the broker Application Server in order to redeem e-
coins to get the money value. The broker provides the “BrokerVendor” Web Service
interface allowing the vendors to send all the redeem details to the broker at the end of
business day. The broker verifies the e-coins and redeems the e-coins in money value
76
and deposits it into the respective vendors’ account. The vendors redeem spending
with broker is illustrated in Figure 4-10
Figure 4-10 Redeem spending e-coins with broker
Redeem C# – vendor request for redeem spending with the broker by connecting to
BrokerVendor Web Service.
BrokerVendorWebChannel – provides “BrokerVendor” Web Service interface to
vendors to request for redeem spending. The spent e-coins are verified by the broker
77
database and the balance is returned to the vendor’s interface via the same Web
Service interface.
4.3.2 Dynamic System Design
In order to document the OOD dynamic system design we used UML diagrams as it
provides a larger number of dynamic models. Dynamic structure of M&E-NetPay
system is described by dynamic models which also demonstrate the interaction
between system object and not the object classes. We refine and present the sequence
diagrams described in section 3.5.2.
78
4.3.2.1 Buy e-coins
Figure 4-11 shows the UML sequence diagram of how the M&E user buys e-coins
from the broker. New and existing M&E users (if they run out of e-coins) enter the
amount and click on buy button. The request is delivered to the broker in a light weight
XML-based message via Web Services. The broker debits the M&E user’s credit card,
generates and stores the e-coins in the database. The M&E user views the updated
balance.
Figure 4-11 Buy e-coin sequence diagram
79
4.3.2.2 Download File
Figure 4-12 shows the UML sequence diagram of how the M&E user buys services
from the vendor. After searching for the desired file (e.g. wallpaper) the M&E user
clicks on “Download” button. The M&E-NetPay system sends the client information
and the e-coins from the E-wallet to the vendor. The vendor receives T&I information
from the M&E user’s previous vendor or from the broker via Web Service interfaces.
If e-coins are valid the current vendor debits the e-coins and downloads the purchased
wallpaper which is downloaded on to the M&E user’s mobile or PC.
Figure 4-12 Download wallpaper sequence diagram
80
4.3.2.3 Redeem Spending
Figure 4-13 illustrates how a vendor redeems spent e-coins with broker. When
redeeming spent e-coins the vendor clicks on redeem button on the vendor site. The
system aggregates all payments and sends it to broker application server where it
verifies spent e-coins and credits the vendor’s account.
Figure 4-13 Redeem spending sequence diagram
81
4.4 Database Design
Database is a system intended to organize, store and retrieve large amount of organized
collection of digital data easily. For the implementation of M&E-NetPay system we
designed three relational databases; one broker database and two vendor databases.
4.4.1 Broker database
The M&E-NetPay broker database consists of four tables. Figure 4-14 shows the
broker database table and their relationships.
� Customer – contains M&E users’ personal and credit card information.
� Ecoin – contains all the information about e-coins generated by broker and the
M&E user associated with it. E-coin fields are “Root”(W0) which is used to
generate the first e-coin, “Seed” (Wn+1) prevents M&E users and vendors from
overspending and forging paywords in a payword chain, “Amount” (n) is the
number of e-coins the M&E user has bought and “Chain” contains n number of
paywords and each payword contains thirty-two characters.
� CardType – contains a set of credit card types that are accepted by the broker to
buy e-coins.
Figure 4-14 Broker System database ERD
82
� VendorHost - it keeps track of all the vendors a M&E user has visited. The e-
wallet of the M&E-user resides on the last vendor the user visited. The M&E user
is authenticated using the e-coin ID.
When the M&E user gets registered with the broker his/her personal and bank
information are stored into the Customer table and when the registered M&E user
buys e-coins, the broker generates the e-coins and saves it into the Ecoin table with
the M&E user assigned to it. One M&E user can do multiple purchase of e-coins.
Every time the M&E user buys e-coins from the broker a new e-coin ID is issued
to him/her.
4.4.2 Vendor Databases
4.4.2.1 Wallpaper Database
The Wallpaper database consist if five tables as shown in Figure 4-15.
� Wallpaper stores wallpaper information. The inofrmation it captures are Title,
Category of wallpaper, movie the wallpaper is taken from, the date it is posted
online, the price of the wallpaper, description if there is any and the location
where the wallpaper is saved.
� Category stores all the possible categories of wallpapers.
� Movie stores all possible list of movie names the wallpaper belongs to.
� TandI contains touchstone and index of an e-coin. When the M&E user
downloads a wallpaper from Wallpaper-vendor, the Wallpaper-vendor stores the
touchstone and index assuming that M&E user will download more wallpaper
instantly after first download. The Wallpaper-vendor gets the touchstone and
index from M&E user’s previous vendor or broker if previous the vendor is
unavailable.
� Redeem contains e-coins for redeem spending with broker.
� BrokerHost contains broker’s host and site name
83
Figure 4-15 Wallpaper system database ERD
Similar to Wallpaper database the Ringtone database contains five tables as shown in
Figure 4-16. The ringtone database tables includes TandI, Redeem, Ringtone, Category
and Movie.
� Ringtone stores all ringtones information. The inofrmation it captures are Title,
Category of ringtones, movie the music is taken from, the date it is uploaded on the
site, the price of the ring-tone, description if there is any and the location where the
ring-tone is saved.
� Category stores all the possible categories of ring-tones.
� Movie stores all possible list of movie names the ringtone music belongs to.
� TandI contains touchstone and index of an e-coin. When the M&E user downloads
a ringtone from the Ringtone vendor, the Ringtone-vendor stores the touchstone and
index assuming that M&E user will download more ring-tones instantly after first
download. The Ringtone-vendor gets the touchstone and index from the M&E-
user’s previous vendor or broker if previous vendor is unavailable.
� Redeem contains e-coins for redeem spending with broker.
84
� BrokerHost contains broker’s host and site name
Figure 4-16: Ringtone system database ERD
85
4.5 M&E NetPay Implementation
We have implemented one broker and two vendor sites. All applications were
developed on .NET platform, framework 4.0. We used Microsoft Visual Studio 2010
ASP.NET and C# programming language for front-end implementations and Microsoft
SQL Server 2005 for our database storage. The broker and vendors provide access to
both mobile and internet users published on the web servers’ IIS. Web service
interfaces are implemented on the application servers’ IIS to provide access to internal
as well as to remote sites. Figure 4-17 shows Web Service references on the broker
site referenced from Broker Web Service on the application server.
<applicationSettings>
<BrokerWebApp.Properties.Settings>
<setting name="BrokerWebApp_Customer_CustomerChannel" serializeAs="String">
<value>http://localhost/BrokerWebService/CustomerChannel.asmx</value></setting>
<setting name="BrokerWebApp_CardType_CardTypeChannel" serializeAs="String">
<value>http://localhost/BrokerWebService/CardTypeChannel.asmx</value></setting>
<setting name="BrokerWebApp_Ecoin_EcoinChannel" serializeAs="String">
<value>http://localhost/BrokerWebService/EcoinChannel.asmx</value></setting>
<setting name="BrokerWebApp_VendorHost_VendorHostChannel" serializeAs="String">
<value>http://localhost/BrokerWebService/VendorHostChannel.asmx</value></setting>
</BrokerWebApp.Properties.Settings>
</applicationSettings>
Figure 4-17: Code for Web Service references on the broker web application.
4.5.1 Broker
The broker manages M&E user and vendor accounts, e-coin creation and spending e-
coin redemption, touchstone supply for e-coin verification, and macro-payment
handling for e-coin purchase by M&E users and payment to vendors for spent e-coins
[3]. Our broker database holds all the M&E users’ and vendors’ information,
application server provides business functions, Web Service interfaces for broker.
Vendor application servers and web server provides Active Server Pages (ASP.NET)
with ASPX extension-implemented on WML interfaces for mobile users and HTML
(Hyper Text Markup Language) interfaces for Internet users.
86
(a) WML interfaces for mobile phone users
(b) HTML interfaces for Internet users
Figure 4-18: M&E users purchasing e-coins from broker
The Web Service interface allows vendors to request for e-coin touchstone and index
information, help vendors to verify e-coins, redeeming of spent e-coins by vendors.
We chose to replace CORBA with Web Service to provide interoperability (i.e.
platform-independent and language-independent). Figure 4-18 shows M&E user
purchasing e-coins from broker. The user registers with the broker to have their
money account created (1). The M&E user needs to login using the provided
(3) (2) (1)
(4)
(4) (3)
(2) (1)
87
customer id and password (2). In order to buy e-coins the M&E user needs to
authorize macro-payment by the broker (3) and the bank debits the M&E user’s
account paying for e-coins (4).
4.5.2 Vendor
Vendor implementation provides M&E users with ASP.NET pages to browse through
their entire site. In our case we implemented Ringtone and Wallpaper sites. There are
also search facilities provided to M&E users to search for desired ringtones or
wallpapers. The search result shows a brief summary of the ringtone or wallpaper with
download cost as shown in Figure 4-19 (1). After downloading an item, the ASP.NET
pages is refreshed to indicate the amount of e-coins left with the current vendor in the
M&E user’s e-wallet (2).
(a) WML interfaces for mobile phone users
(b) HTML interfaces for Internet users
Figure 4-19: M&E User spending e-coins at the Ringtone site.
(1)
(1) (2)
(2)
88
When the M&E user first tries to download an item, the vendor obtains the validating
touchstone and index from the broker through Web Service interface provided by
broker. When going to another vendor the current vendor obtains the valid touchstone
and index from the previous vendor through the Web Service interfaces provided by
other vendors.
4.5.3 Customer (M&E User)
We have provided WML/HTML interfaces for both mobile and Internet users to allow
a wide range of M&E users access broker and vendor sites using standard web
browser. The use of thin-client technology implementation eradicates the need to
install separate browsing software on the client’s site. The M&E users use
WML/HTML based ASP.NET pages to browse through broker and vendor sites. The
e-wallet of the M&E user is hosted on the server side and transferred from vendor to
vendor as the M&E user purchases item(s) from those vendors.
4.6 Implementation and Experience
We have used Active Server Pages (ASPx) to implement the M&E-NetPay
micropayment system. In order to connect remote systems we used Web Services
interfaces. All communications between Presentation and Business Components are
achieved via Web Services whether it is within the system or between the systems.
Web Services uses SOAP and XML-based messages to achieve a fast, secure and
cheap communication amongst systems.
To make the M&E-NetPay system more effective and efficient we split the system into
three components: the presentation logic which determines how the information is
presented to the M&E users; business components which controls the relationship
between inputs and determines business rules; data adapter layer which connects to the
database, executes relevant queries and returns the results back to the upper layers. We
used HTML with ASP controls for the design of web pages and C# programming
language was used to implement the back end of the application.
We have used Web Services as the middleware for our M&E-NetPay system. Web
Services interfaces was implemented on .NET framework 4.0 which enables small and
89
enterprise applications to connect to other applications over Internet. Web Services
also has greater advantages over OMG’s CORBA middleware. Web Services on .NET
framework is widely available in the area of object oriented and distributed systems.
Moreover, it adds in a new functionality of interoperability which supports
independence of development platform and programming languages to be used. It
allows vendors and broker to use their choice of programming language and operating
system platform for the implementation of their system. Therefore, a vendor
implemented using C# programming language and running on Windows operating
system can easily communicate with a vendor implemented using C++ programming
language and running on UNIX operating system.
4.7 Summary
In this chapter we presented the software architecture of our M&E-NetPay system.
Software architecture provides a high-level structure of the M&E-NetPay system and
also addresses the complexity of our system. OOD was used to describe the design
level of the M&E-NetPay system. The class diagrams and sequence diagrams
describes static and dynamic behaviours of the M&E-Neypay system. Entity
Relationship Diagram (ERD) shows related tables and the fields of broker and vendor
databases. We describe each table and its attributes in detail. The implementation and
user interaction with examples are presented to support the design of M&E-NetPay. In
the next chapter we will evaluate the M&E-NetPay system to determine the efficiency
and effectiveness of the system.
90
Chapter 5: EvaluationIn this chapter we describe the three types of evaluation methods which are used to
assess the usability of M&E-NetPay system and to assess our system with comparison
with other payment systems. The first two are performance impact and heuristic
evaluation which does not include users working with the product [58]. The third
method is usability evaluation which focuses on users working with the product. This
method also includes direct questions to users while they are performing the task.
5.1 Motivation
After implementing M&E-Netpay system we now want to gauge its simplicity
compared with other payment systems. We choose to compare M&E-Netpay system
with a CORBA-based NetPay system [1, 3, 59]. CORBA-based NetPay is a debit-
based mobile micro-payment system which uses one-way hash function to generate a
payword chain. NetPay uses CORBA interfaces as middleware to provide
communication amongst vendors and broker. We also implemented the NetPay
application for comparison.
To assess the characteristics of M&E-NetPay system we compare it with CORBA-
based NetPay system. We engage M&E users to use the M&E-Netpay system and
provide feedback on its usability. We want to evaluate the M&E-NetPay system from
several perspectives to get a better understanding of M&E user’s needs. We also want
to evaluate the advantages and disadvantages of users’ feedback while using M&E-
NetPay system. There are many micro-payment systems in existence in M&E
environment however many of them suffered from dependency of online brokers,
scalability, performance and interoperability problems. The new M&E-NetPay model
guarantees high-volume, low value, cheap e-coin encryption via one-way hashing,
offline micro-payment (does not involve broker in every transaction), prevents
customers from double spending, protects forging and fraud by users, vendors and
outsiders, prevents anonymous payment and is platform and language independence.
These properties have been achieved via one-way hashing mechanism embedded in
broker system and use of simple XML based Web Services with .NET framework 4.0
on both vendor and broker systems.
91
The performance impact evaluation of M&E-NetPay was used to determine the
usability of such system in M&E environment. Heuristic evaluation was carried out to
assess the user interface based on a set of usability principles [60]. Usability
evaluation was carried out to obtain quantitative data about test participants'
performance when they perform the tasks during usability test and via answering direct
questions [11]. In the following sections we report the result of:
� Performance evaluation to verify whether M&E-NetPay would be acceptable in
M&E environment.
� Heuristic evaluation is used to validate whether M&E-Netpay meets the
requirements for a micro-payment system for purchasing items via M&E
environment.
� Usability evaluation to determine whether M&E-NetPay is usable as far as target
users are concerned.
5.2 Performance Impact Evaluation
Performance is an important quality attribute of software systems. Performance
failures results in damaged customer relations, lost productivity for users, lost revenue,
cost overruns due to tuning or redesign, and missed market windows [61]. We assess
the performance of M&E-NetPay system against the CORBA-based NetPay system in
regards to user response time.
5.2.1 Procedure
We carried out a test for client response time with ten tests. The main aim of this
evaluation is to test how long it takes to download a wallpaper from the time the
customer clicks on the download link till the time the file is downloaded. The users
downloaded the same file from both M&E-NetPay and CORBA-based NetPay system.
The response time of searching for wallpaper, buying of e-coins and redeeming e-coins
was also noted. Our prototypes were deployed over multiple machines connected via
high speed LAN.
92
5.2.2 Results
We present the result of downloading of wallpaper with both the systems. M&E-
Netpay and CORBA-based NetPay system are shown in Table 5-1. The response time
delay is the time taken for a wallpaper to be downloaded. All ten clients downloaded
the same wallpaper having size of 38.4KB.
Table 5-1 Results of Downloading Wallpaper
Test
Response delay time with
M&E-NetPay (ms)
Response delay time with
CORBA-based NetPay
(ms)
1 2149 24102 2390 25093 1734 22944 3065 23545 2012 24326 1976 20917 2190 22568 1734 21689 1637 200510 1815 2344
Average 2070 2286
93
Figure 5-1 Response delay time of downloading wallpaper
The above result shows that the response delay time of downloading a wallpaper is
slightly higher with CORBA-based NetPay. When the client downloads wallpaper
using M&E-NetPay system it takes an average of 2070 milliseconds. For CORBA-
based NetPay system it takes an average of 2286 milliseconds to download the same
wallpaper. There was a difference of 216 milliseconds and this was due to CORBA’s
weaknesses with client-to-server communications. Moreover .Net framework
architecture 4.0 with Web Services in M&E-NetPay has improved client-to-server
communications. Hence it provides a fast, secure and cheap communications amongst
vendor and broker systems.
0
500
1000
1500
2000
2500
3000
3500
1 2 3 4 5 6 7 8 9 10
Res
pons
e Ti
me
(ms)
Number of Tests
Response Delay Time of Downloading Wallpaper
Response delay time with M&E-NetPay (ms)
Response delay time with CORBA-based NetPay (ms)
94
Table 5-2 Results of Searching Wallpapers, Buying and Redeeming E-coins
Average response delay time
with M&E-NetPay (ms)
Average response delay time
CORBA-based NetPay (ms)
Search wallpapers 1501 1703
Buy E-coins 895 920
Redeem E-coins 1990 2110
The results in Table 5-2 shows that the searching of wallpaper via M&E-NetPay is 202
milliseconds faster than searching of wallpaper via CORBA based NetPay. Since
M&E-NetPay is deployed over multiple servers to share workload and is built on a
more stable, secure and simple architecture, the response delay time is lesser than
CORBA-based NetPay system. Buying of e-coins and redeem e-coins are also faster
with M&E-NetPay.
5.3 Heuristic Evaluation
Heuristic evaluation technique is the most widely used inspection method. This
method is for finding usability issues in a user interface by having a small number of
evaluators (usually one to five) examine the interface and judge its compliance with
usability principles (heuristics) [58]. The results from observations represent the
evaluator's opinion about what needs to be improved in a user interface [58]. Heuristic
reviews are cheap and less time consuming. The results will also bring good ideas for
improving the user interface.
Usability problems found are normally restricted to aspects of the interface which are
reasonably easy to demonstrate: use of colours, lay-out and information structuring,
consistency of the terminology, consistency of the interaction mechanisms. It is
generally agreed that problems found by inspection methods and by performance
measures overlap to some degree, although both approaches will find problems not
found by the other.
Each individual evaluator inspects the interface alone and only after the evaluations
have been completed the evaluators are allowed to communicate and have their
findings aggregated. This procedure is important in order to ensure independent and
95
unbiased evaluation from each evaluator. This method will provide recommendations
for design improvements. As this method relies on experts, the output will naturally
emphasize interface functionality and design rather than the properties of the
interaction between an actual user and the product.
The method provides proper planning of experts to be established in good time for the
evaluation. While running the evaluation the experts should be aware of any relevant
contextual information relating to the intended user groups, tasks and usage of the
product. At the end of evaluation the experts provide a report containing a list of
identified problems which may be prioritized with regard to severity and/or safety.
5.3.1 Design
We chose 5 evaluators to examine the M&E-NetPay interface and judge its compliance
with usability principles (“the heuristic”). Each individual evaluator inspected the
interface alone.
To aid the evaluators in discovering usability problems, a list of heuristics was
provided to them which could be used to generate ideas while evaluating the system as
shown in Table 5-3 [69] .
96
Table 5-3 Details of Heuristic Employed
Number Heuristic
1 Visibility
2 Functionality
3 User Control and Freedom
4 Consistency
5 Help Recover From Errors
6 Error Prevention
7 Memorability
8 Flexibility
9 Aesthetic
10 Help and documentation
We provided a system checklist (see Appendix A) based on the heuristics to the
evaluators to use as a guide. The evaluators were required to use the severity rating
shown in Table 5-4 [69] to determine the seriousness of each problem. The evaluators
were asked to identify the heuristic problems and provide recommendation based on
the severity rating.
Table 5-4 Severity of heuristic evaluation
Rank Interpretation
1 Cosmetic problem only
2 Minor usability problem
3 Major usability problem
4 Catastrophic
5.3.2 Results
The five evaluators evaluated the M&E-NetPay system with the set of heuristics. Two
of the evaluators were IT specialist, one of evaluators was an Accountant and the other
two were new graduates. The results of the heuristic evaluation are shown in Table B-1
(see Appendix A).
97
Severity rating has four levels of problem from which one and two are minor and are
not important to fix. Problem levels of three and four are given high priority and are
vital to fix. After the evaluation we identified three major problems and all these has a
severity rating of three. The discussion of each problem with recommendation is
shown in Table 5-5.
Table 5-5 Summary of FindingsNumber Problem Recommendation Severity
Ranking
Heuristic
Number
1 No error message is
displayed for invalid entries
Appropriate error message
should be displayed for
invalid entries
3 5
2 Exit button not provided to
exit application from any
screen.
Exit button should be
implemented on every screen
3 2, 3
3 No help topics provided Implement help topics as
users may not be aware of the
function of menu or
command button.
3 10
We implemented all the recommendations discussed above.
98
5.4 Usability Evaluation
Usability evaluation involves testing of usability of a user interface by having a group
of individuals performing tasks specific to a system under gentle guidance from a
facilitator.It is important to realize that usability is not a single, one-dimensional
property of a user interface. Usability is a combination of factors including [66]:
� Ease of learning - How fast can a user who has never seen the user interface
before can learn it sufficiently well to accomplish basic tasks?
� Efficiency of use - Once an experienced user has learned to use the system, how
fast can he or she accomplish the tasks?
� Memorability - If a user has used the system before, can he or she remember
enough to use it effectively the next time or does the user have to start over again
learning everything?
� Error frequency and severity - How often do users make errors while using the
system, how serious are these errors, and how do users recover from these errors?
� Subjective satisfaction - How much does the user like using the system?
There are eight guidelines of usability evaluation as shown below in Table 5-6 [65].
99
Table 5-6 Guidelines of usability evaluation
Guidelines
1. Choosing your subjects:
The results will only be as good as the people you test.
2. Before the usability testing:
Each participant must be put at ease.
Provide clear instructions on how to get to the usability testing location
3. Beginning the usability testing:
Before diving into key tasks, get the user familiar with the environment. Tell them the
website's name and URL, and ask them for initial feedback on what they would
expect from the site or what they would like the site to be.
4. Choosing tasks:
Set tasks that are essential to the new site's success, such as:
Buying products
5. How to word tasks:
People tend to perform more naturally if you provide them with scenarios rather than
instructions
6. Presenting tasks:
Only give participants one task at a time. More than this may intimidate them, or alter
their approach to the test.
7. How to behave during the usability testing:
It's essential that you remember that it's the website that is being tested, not you or the
subject. Any feedback you get is valuable - make sure the participant knows this. If
they cannot do something, make sure they know it's not their fault.
8. After the usability testing:
You should gather as much information as possible. Asking for overall impressions of
the site will allow you to judge whether expectations have been met, and whether the
participant's view of the client or site has changed during the process.
100
5.4.1 Design
We evaluated the participants’ user satisfaction, buying e-coins, downloading
wallpapers and general preference for the two systems – a CORBA-based NetPay
system and M&E-NetPay system. M&E-NetPay is deployed over three servers:
� Web Server hosts the presentation layer
� Application Server hosts Web Services, business logic components and data
adapter layer
� Database Server hosts the relational database
The CORBA-based NetPay system is deployed over two servers:
� Web Server host JSP pages and CORBA middleware
� Database Server hosts the relational database
We recruited 14 participants to carry out a set of task using our two prototypes.
Participants were an equal mixture of non- IT specialists, graduate students and college
students who volunteered to perform the usability evaluation for our M&E-NetPay and
CORBA-based NetPay systems. Participants filled a pre-test questionnaire (see
Appendix B) before they commence with the test. They were asked to fill the post test
questionnaire (see Appendix B) after they finished with the task given to them. The
participants ranked the systems in order of preference.
Participants were asked to complete the following task on M&E-NetPay and CORBA-
based NetPay system.
� Create account with broker
� Search for wallpaper on wallpaper vendor site
� Download wallpaper from wallpaper vendor
� Download ringtone from ringtone vendor
� If e-coins run out, user must buy more e-coins from broker
� Redeem e-coins with broker
Participants carried out all the tasks listed in the task list for both the systems and then
they filled the post-test questionnaire that contained a subject rating assigned to each
question.
101
5.4.2 Results
The Post-test questionnaire contains a scale rating ranged from 1 to 5 where 1 is “least
favorable” and 5 is “most favorable”. The post-test questionnaire also contained open
questions for users to provide feedbacks. We analyzed the post-test questionnaire
outcomes and presented the results as shown in Figure 5-2.
Figure 5-2 Usability Test Results on Usability features
The result in figure 5-2 shows that all the usability features significantly favors the
M&E-NetPay system. M&E-Pay system is easy to learn because it has user friendly
interfaces and provides clear instructions to accomplish any task. M&E-NetPay also
has a high efficiency rating. Participants mentioned that the speed of downloading file
(i.e. wallpaper, ringtone) is quite fast with M&E-NetPay and with a few clicks they
were able to download the file. They also commented that appropriate error messages
prevented them from going out of track. The overall average rating of M&E-NetPay
and CORBA-based NetPay system is 4.5 and 3.8 respectively. The above result is
greatly achieved by employing new and emerging distributed middleware technology
(i.e. Web Services). Therefore participants prefer M&E-NetPay system more that
CORBA-based NetPay system.
In the feedback of open questionnaires, participants noted that since M&E-NetPay is
available via both mobile and web they will be able to access the system from
anywhere at any time with barely any downtime.
102
5.5 Summary
We used three kinds of evaluation methods to assess the usability of M&E-NetPay
system. These were performance impact, heuristic evaluation and usability evaluation.
We compared the performance and usability of CORBA-based NetPay and M&E-
Netpay system. Even though heuristic evaluation provided a few errors, it was
successfully implemented. The overall result illustrates that most participants preferred
M&E-NetPay system. Participants and evaluators were very much satisfied with
M&E-NetPay system endorsing the system for wide use.
103
Chapter 6: Conclusion and Future workThis chapter provides the summary of the work done in this thesis and also suggests
some possible research in this area for future work.
6.1 Contributions
Many micro-payment systems are in existence now but most still suffer problems
pertaining to security, scalability, performance and interoperability. Some of the
micro-payments systems reviewed in this thesis are MPS [67], CMP [68] and NetPay
[3]. This thesis contributes to some major research in the area of micro-payment.
Firstly, we evaluated three micro-payment systems and compared them using the eight
evaluation criteria to identify the problems that still exist with these micro-payments.
These three micropayment systems are then compared and contrasted with M&E-
NetPay system to determine its effectiveness in the M&E environment. We used OOA
to determine the overall functionality and dynamic interaction of M&E-Netpay system.
M&E-NetPay is an improved version of CORBA-based NetPay micropayment system.
Secondly, the software architecture of M&E-NetPay system is presented and the
OOD is used to describe the design level of the system. The software architecture is
designed with Web Services sitting on top of .Net framework 4.0. M&E-NetPay
system has a thin-client n-tier architecture and supports both mobile and web
applications. M&E-NetPay uses server-side e-wallet which resides on the broker’s
database until the M&E user logs on to any vendor site. The e-wallet is stored on the
last vendor the M&E user visited. M&E-NetPay is distributed along Web, Application
and Database servers to share workload.
Thirdly, we implemented the prototype of a broker and two vendors. The broker
database holds all the M&E users’ and vendors’ information. Application server
provides business functions. Web service provides interfaces for broker and vendor
application servers and web server provides Active Server Pages (ASP.NET) with
ASPX extension-implemented on WML interfaces for mobile users and HTML (Hyper
Text Markup Language) interfaces for Internet users. Vendors provide M&E users
104
with ASP.NET pages to browse through their entire site. WML/HTML interfaces are
provided for both mobile and Internet users to allow a wide range of M&E users to
access broker and vendor sites using standard web browser. Web Services interfaces
are used to provide communications between the broker and vendors for requesting
touchstone and index, connecting to broker, browsing and downloading file and
redeeming e-coins. The vendor database holds information for file, e-coins, touchstone
and index and redeem.
Lastly, we evaluated the M&E-NetPay system using three evaluation methods which
includes performance impact evaluation, heuristic evaluation and usability evaluation.
Performance impact evaluation assessed the efficiency and effectiveness of M&E-
NetPay with CORBA-based NetPay in regards to user response time. Users favored
M&E-NetPay as it recorded a lower response time.
Heuristic evaluation identified the usability issues in the M&E-NetPay user interfaces
using a set of heuristics by five evaluators. Each individual evaluator inspects the
interface alone and provides opinion about what needs to be improved in a user
interface. Usability evaluation was carried to obtain quantitative data about testing
participants' performance and to determine whether M&E-NetPay is usable as far as
target users were concerned. Users used the prototype to assess their impressions of the
approach when purchasing a wallpaper/ringtone using M&E-NetPay system versus
CORBA-based NetPay system. Users gave preference to M&E-NetPay system over
CORBA-based NetPay system.
105
6.2 Conclusion
In this thesis we analysed some existing micro-payment systems and examined its
advantages and disadvantages in the M&E environment. We propose new protocol
M&E-NetPay which is suitable for micropayments on M&E environment. This
protocol provides interfaces for both mobile and Internet users to purchase goods and
services online. M&E-NetPay aims to ease the communication processes between
M&E users, vendors and broker. It is cheap, secure, effective and efficient protocol
and provides low value, high volume transactions since it uses one-way hash functions
to generate paywords rather than using private and public key operations.
M&E-NetPay protocol is based on CORBA-based NetPay protocol [3]. We developed
M&E-NetPay protocol on .NET platform and replaced CORBA middleware with Web
Services since Web Services carry greater advantages over CORBA when developing
mobile applications. M&E-NetPay protocol is an offline distributed system that does
not involve broker when purchasing services from the vendors. Broker is responsible
for generating payword chains for M&E users who wants to buy e-coins. During
transactions the current vendor contacts the broker only if the previous vendor of the
M&E user is offline. This protocol prevents double spending and forging of e-coins by
vendors, M&E users the other third parties. Moreover the anonymity of the M&E user
is fully protected from vendors therefore vendors have no idea who their customers
are. In MPS protocol [67] smart card device cannot guarantee multiple payment
protection.
In terms of transferability the e-coins can be transferred freely between vendors’ for
multiple purchases in M&E-NetPay. Web Service interfaces provide extra simplicity
on transferring e-coins between vendors. Transferability is an important criterion
which improves anonymity and performance of micropayment systems. MPS protocol
has low transferability since payment chains in MPS protocol can only be transferred
between the nodes on the ad hoc network. On a new network the user needs to buy
another payment chain from the new broker.
The main features of M&E-NetPay protocol are mobility and interoperability. The
mobility factor helps M&E-NetPay support both web and mobile users.
106
Interoperability feature minimizes the complexity of software development by reusing
components (components within the system) and performing inter-component
(components between systems) communication and is language & platform
independent (i.e. a client program can be programmed in C# and running on Windows
platform, while the Web Services is programmed in Java and running under Linux).
Therefore M&E-NetPay system has a greater scalability and performance features as it
can support rapidly growing number of M&E users. CORBA-based NetPay has low or
no mobility feature since CORBA’s tight coupling between clients and servers can
only support static networks and has medium interoperability since it can only support
few platform and programming languages.
We choose a thin-client n-tier mobile & web based software architecture for M&E-
NetPay system. This will allow a large number of users to access M&E-NetPay
system. Web Services are used with .NET framework 4.0 to support inter-connection
between remote sites. Mobile users use the WML based web browser to access vendor
and broker sites which has got small interfaces suitable to fit on mobile phone’s screen
whereas Internet users use HTML based web browser on their PCs to access vendor
and broker sites. M&E-NetPay application’s deployment architecture is designed
keeping in mind some general qualities of performance, security, availability and
serviceability. M&E-NetPay is distributed along multiple servers to share workload.
We host mobile & web applications on the Web Servers, Web Services on the
Application Servers and SQL Databases on the Database Servers. Web Services on
Application servers is only available on requests from mobile and web applications on
Web servers. Only authenticated users within the network will be able to log on to the
Application Servers.
We implemented server-side e-wallet for M&E-NetPay system using Web Services on
.NET framework 4.0. Mobile and web applications are published on the Web Server’s
IIS whereas Web Service Interfaces are published on the Application Server’s IIS.
Server-side e-wallet allows M&E users with mobility and accessibility anywhere
features. In the server-side e-wallet of M&E-NetPay system, the touchstone and index
(T&I) of the M&E users are passed from the broker to each vendor the M&E user
visits. The M&E user’s e-wallet resides on the last vendor he/she has visited. Web
Services enables the M&E user’s current vendor to communicate with his/her previous
107
vendor to get T&I to verify e-coins. The vendor communicates with the broker for T&I
only if that vendor is the M&E user’s first vendor or if the previous vendor of the
M&E user is off-line. Broker is responsible for generating, verifying and redeeming of
e-coins.
We have provided WML/HTML based ASP.NET interfaces for both mobile and
Internet users to allow a wide range of M&E users to access broker and vendor sites
using standard web browser. A well designed search feature is available for M&E
users to search for items online. Help features are also provided to M&E users who
find difficulties in using M&E-NetPay system.
M&E-NetPay system is assessed using three types of evaluation methods. We
compared our M&E-NetPay system with the CORBA-based NetPay system.
Performance impact evaluation was carried out to determine the transparency of M&E-
NetPay over CORBA-based NetPay system. Heuristic evaluation was to examine the
interface and judge its compliance with usability principles. Usability evaluation tests
the usability of M&E-NetPay and CORBA-based NetPay user interfaces by having a
group of individuals performing tasks specific on the system.
Performance impact evaluation compared the downloading of wallpaper with M&E-
NetPay versus CORBA-based NetPay. The result showed that the response delay time
of downloading wallpaper is slightly higher with CORBA-based NetPay. M&E-
NetPay took an average of 2070 milliseconds whereas CORBA-based NetPay took an
average of 2286 milliseconds to download the same wallpaper. There was a difference
of 216 milliseconds that was due to CORBA’s weaknesses with client-to-server
communications and the use of .Net framework architecture 4.0 with Web Services in
M&E-NetPay has improved client-to-server communications
In heuristic evaluation, each evaluator inspected the interface alone and provided
comments on improving the user interface. Problem levels of three and four were
given high priority and were vital for fixation. All recommendations with severity
rating of three and above were implemented.
108
Usability evaluation provided a good method of assessing and understanding users’
perception of using M&E-NetPay systems. Usability evaluation helped evaluate
advantages and disadvantages users saw while using M&E-NetPay system. Usability is
multiple dimension property of a user interface. We tested the usability of M&E-
NetPay and CORBA-based NetPay using a combination of usability factors which
includes: ease of learning, efficiency of use, memorability, error frequency and
severity, and subjective satisfaction. The result showed that usability features
significantly favored M&E-NetPay system. The overall average rating of M&E-
NetPay was 4.5 and CORBA-based NetPay system was 3.8. This result is achieved by
employing new and emerging distributed middleware technology (i.e. Web Services).
Participants also noted that using mobile phone to access M&E-NetPay was quite
helpful as they are be able to access it from anywhere. Hence participants prefer M&E-
NetPay system more than CORBA-based NetPay system.
6.3 Future work
M&E-NetPay micropayment system suffers from limitations with communication
and technology (i.e. Web Services). A limitation with communication occurs when
V2 requests for T&I and e-coins from V1 and V1 is off-line. When V1 is not available
during the time of request there is a breakdown of communication. In order to allow
minimum or no downtime V2 connects to a broker to request T&I and e-coins. This
means that the broker sometimes is online with vendors to deal with the downtime.
Even though there are constrains with communication, this will preserve and
improve the security aspects of M&E-NetPay system. Issues with Web Services are
that it lacks versatility; it only allows some very basic form of service innovation.
There are a lot of Web Services specifications emerging that will help Web Services
become more and more versatile in future.
This thesis completely described the protocol, architecture, design and implementation
of M&E-NetPay system. M&E-NetPay system has got better and improved
functionalities than other micro-payment systems. M&E-NetPay is superior to other
micropayment systems in many ways such as it is cheap, secure, effective and efficient
micro-payment protocol and provides low-value, high volume transactions. The main
109
features of M&E-NetPay system are mobility and interoperability. However, there are
still some research areas that need to be completed in the future.
We still need to test the performance of our M&E NetPay system with other micro-
payment systems from several other perceptive and provide architecture to support
multiple brokers. We hope to explore further advantage of Web Services and provide a
generalization of our architecture for a wider range of M&E-commerce components.
We will also need to venture into future works for existing web sites and temporary
vendors such as:
� Create some Web Services components in M&E broker which could be used to
inject the NetPay components/services to support any existing ASP.NET-based
web site or other websites such as PHP and JSP without further programming on
it.
� There is currently no way for some vendors who only want to use M&E-NetPay
facilities temporarily. A portal infrastructure could be designed using Web
Services that will allow a NetPay-enabled vendor to act as a purchasing portal to
non-M&E-NetPay supporting vendors by redirecting page accesses to these
vendors and charging the customers e-coins in the process.
110
Reference[1] Dai, X. and Ayoade, O.: “Comparing and Contrasting Micro-payment Models for
Mobile Commerce Systems”, International Review on Computers and Software
(I.RE.CO.S), 2007. Publisher: Praise Worthy Prize S.r.l.
[2] Dai, X. and D, Baran.: “ NetPay: A Prototype of Account-based Payment M-COM
System in M-Commerce”, International Review on Computers and Software
(I.RE.CO.S.), 2007.
[3]Dai, X. and Grundy, J.: “Architecture of a Micro-Payment System for Thin-Client
Web Applications”, In Proceedings of the 2002 International Conference on Internet
Computing, Las Vegas, CSREA Press, June 24-27, 444-450.
[4] Furche, A. and Wrightson, G.: “SubScrip – An efficient protocol for pay-per-view
payments on the Internet”, The 5th Annual International Conference on Computer
Communications and Networks, USA, 1996.
[5] Herzberg, A. and Yochai, H.: "Mini-pay: Charging per Click on the Web", 1996,
http://www.ibm.net.il/ibm_il/int-lab/mpay
[6] Microsoft Corporation, 2011, Chapter1: What is Software Architecture,
http://msdn.microsoft.com/en-us/library/ee658098.aspx
[7] Hwang, M. and Lin, I. and Li, L.: “A simple micro-payment scheme”, Journal of
Systems & Software, vol.55, no.3, Jan. 2001, Elsevier, pp.221-9.
[8] Manasse M.: "The Millicent Protocols for Electronic Commerce", First USENIX
Workshop on Electronic Commerce, New York, 1995.
[9] Rivest, R. and Shamir, A., "PayWord and MicroMint: Two Simple Micropayment
Schemes", Proceedings of 1996 International Workshop on Security Protocols, Lecture
Notes in Computer Science v. 1189, page 69-87. Springer, 1997.
111
[10] Gray, N.: Comparison of Web Services, Java-RMI, and CORBA service
implementations,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69.2475&rep=rep1&type=p
df
[11] Performance Measurement,
http://www.usabilityhome.com/FramedLi.htm?PerfMeas.htm
[12] C# and .NET Architecture,
http://media.wiley.com/product_data/excerpt/89/07645439/0764543989.pdf
[13] Schwiderski-Grosche, S., Knospe, H.: “Secure M-Commerce”, pp 3,
http://www.it.iitb.ac.in/~annanda/papers-280905/Secure%20m-
commerce%20ECEJ.pdf
[14] Mallon, D.: Sybase, “mCommerce Security White Paper Key Security
Techniques”, mCommerce Security White Paper Version 1.1, March, 2010.
[15] Wells, D.: Authentication, April 24, 1996,
http://www.objs.com/survey/authent.htm
[16] Tsiounis, Y.: Anonymity in Electronic Commerce, GTE Laboratories, Inc.
http://www.ccs.neu.edu/home/yiannis/papers/LCN.ppt
[17] Dai, X. and Ayoade, O. andGrundy J., “Off-line Micro-payment Protocol for
Multiple Vendors in Mobile Commerce”, The 7th International Conference on Parallel
and Distributed Computing, Applications and Technologies (PDCAT'06), 4-7
December 2006, Published by IEEE Computer Society.
[18] Kuarar, S.: Micro-payments: A Gateway to Future Income?, 2009,
http://www.selimkurar.com/blog/?p=15
[19] Schmidt, C. and Muller, R.: A Framework for Micropayment Evaluation, 1997.
http://edoc.hu-berlin.de/series/sfb-373-papers/1998-66/PDF/66.pdf
112
[20] Manasse, M.: The Millicent Protocols for Electronic Commerce, First USENIX
Workshop on Electronic Commerce, New York, 1995.
[21] Hauser, R. and Steiner, M. and Waidner, M.: “Micro-payments based on ikp”, In
proceedings of 14th Worldwide Congress on Computer and Communications Security
Protection. Paris-La Defense, France: C.N.I.T, 1996, pp 67-82.
[22] DigiCash website. http://digicash.com
[23] Sirbu, M. and Tygar, J.: “NetBill: An Internet Commerce System Optimized for
Network-Delivered Services”, In IEEE Personal Communications, 2, August 4, 1995,
pp. 34-39.
[24] Dai, X. and Lo, B.: NetPay – An Efficient Protocol for Micropayments on the
WWW, Fifth Australian World Wide Web Conference, Australia (1999).
[25] Herzberg, A. and Yochai, H.: Mini-pay: Charging per Click on the Web, 1996,
http://geckil.com/~harvest/www6/Technical/Paper099/Paper99.html
[26] Dai, X. and Grundy J.: Customer Perception of a Thin-client Micro-payment
System Issues and Experiences, Journal of End User Computing, 15(4), pp 62-77,
(2003).
[27] Gisolfi, D.: Web services architect, Part 3: Is Web services the reincarnation of
CORBA?, July 1, 2001,
http://www.ibm.com/developerworks/webservices/library/ws-arc3/
[28] Boukhonine, S.: Cryptography: A security Tool of the Information Age,
http://www.bauer.uh.edu/uhisrc/FTB/Cryptography/FTBCryptography.pdf
[29] Microsoft Corporation, Chapter1: Cryptography, April 19, 2011,
http://msdn.microsoft.com/en-us/library/aa380255(v=vs.85).aspx
113
[30] Kessler, G.: An Overview of Cryptography, February 21, 2011
http://www.garykessler.net/library/crypto.html
[31] Ross, K.:Cryptography - Types of Cryptography, September 25, 2010,
http://ezinearticles.com/?expert=Kate_R_Ross
[32]Wikipedia, Cryptographic hash function, February 13, 2011,
http://en.wikipedia.org/wiki/Cryptographic_hash_function
[33] Friedl, S.: An Illustrated Guide to Cryptographic Hashes,May 9, 2009,
http://unixwiz.net/techtips/iguide-crypto-hashes.html
[34] Yuwathiticharoenwong, U., Permpoontanalarp, Y.: “An Agent-based Approach
to Micropayment System”,
http://www.thaiscience.info/Article%20for%20ThaiScience/Article/6/Ts-6%20agent-
based%20approach%20to%20micropayment%20system.pdfd
[35] Altova, 2006, Web services: Benefits, challenges, and a unique, visual
development solution, Beverly, MA, USA.
[36] Dai, X. and Grundy, J.: NetPay: An off-line, decentralized micro-payment system
for thin-client applications. Electronic Commerce Research and Applications, vol.6,
no.1, Spring 2007, pp. 91-101. Publisher: Elsevier, Netherlands.
[37] Pedersen, T.: Electronic payments of small amounts, Proceedings of 1996
International Workshop on Security Protocols. Berlin, Germany, Springer Verlag,
LNCS No. 1189, 1997, pp 59 - 68.
[38] Park, D. and Boyd, C. and Dawson, E.: Micro-payments for wireless
communications, 3rd International Conference On Information Security and
Cryptology, Lecture Notes in Computer Science 2015, Springer, 2001, pp 192—205
114
[39] CodeGuru, The .NET Architecture, Published by Wiley Publishing, September
21, 2004,
http://www.codeguru.com/csharp/sample_chapter/article.php/c8245__1/The-NET-
Architecture.htm
[40] Microsoft Corporation, 2011, Application Architecture for .NET: Designing
Applications and Services. http://msdn.microsoft.com/en-us/library/ee817664.aspx
[41] C# and .NET Architecture,
http://media.wiley.com/product_data/excerpt/89/07645439/0764543989.pdf
[42] Strehl, R.: , A low-level Look at the ASP.NET Architecture, August 4, 2008,
http://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp
[43] Active Server Pages: What are Active Server Pages?,
http://www.asptutorial.info/learn/Introduction.html
[44] Grundy. J.: 2000, Requirements Engineering & OOA Tutorial.
[45] Grundy, J.: 2000, Software Architecture & Object-oriented Design Tutorial.
[46] Chapter 21 Object-Oriented Analysis,
http://bhaumiknagar.com/Documents/Chapter%2021%20Object-
Oriented%20Analysis.pdf
[47] Use Case Diagrams,
http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htm
[48]Non functional Requirements:
http://www.csee.umbc.edu/courses/undergraduate/345/spring04/mitchell/nfr.html
[49] Mylopoulos, J.: 2004, V. Object-Oriented Modeling,
http://www.cs.toronto.edu/~jm/2507S/Notes04/OOA.pdf
115
[50] Ambler, S.: 2003-2010, Agile Modeling, “UML 2 Class Diagrams”,
http://www.agilemodeling.com/artifacts/classDiagram.htm
[51] Sparx Systems, 2004, UML Tutorial, “The Logical (Class) Model”,
http://www.sparxsystems.com/downloads/whitepapers/The_Logical_Model.pdf
[52] Mishra, R., Lohani, B., An Object-Oriented Software Development Approach to
Design Simulator Forairborne Altimetric Lider.
[53]Microsoft Corporation, 2010, Introduction to Data Adapters,
http://msdn.microsoft.com/en-us/library/acb32th4(VS.71).aspx
[54] Ian Sommerville, 2000, 12. Object-oriented Designx
[55] Pressman, Roger, S.: Software Engineering: A Practitioner’s Approach, 5th
Edition, McGraw-Hill, 2001.
[56] TechTarget, 2011, IIS (Internet Information Server),
http://searchwindowsserver.techtarget.com/definition/IIS
[57] Exforsys Inc, SQL Server 2005 - Introduction to Data Availability, June 1, 2006,
http://www.exforsys.com/tutorials/sql-server-2005/sql-server-data-availability.html
[58] Usability.gov, Usability Methods,
http://www.usability.gov/methods/index.html
[59] Dai, X. and Grundy, J. and Lo, B.: “Comparing and contrasting micro-payment
models for E-commerce systems”, International Conferences of Info-tech and Info-net
(ICII), China, 2001.
[60] Nielsen, J.: Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), “Usability
Inspection Methods”, John Wiley & Sons, New York, 1994.
[61] Williams, L., Smith, C., “Performance Evaluation of Software Architectures”,
Performance Engineering Services and Software Engineering Research, 2007.
116
[62] Nielsen J., How to Conduct a Heuristic Evaluation,
http://www.useit.com/papers/heuristic/heuristic_evaluation.html
[63] Usability.gov, 2006, Heuristic evaluation,
http://www.usabilitynet.org/tools/expertheuristic.htm
[64] Nielsen J.: “Reliability of severity estimates for usability problems found by
heuristic evaluation”, CHI '92 Posters and short talks of the 1992 SIGCHI conference
on Human factors in computing systems, New York, 1992.
[65] 8 Guidelines for Usability Testing, April, 2006,
http://www.webcredible.co.uk/user-friendly-resources/web-usability/usability-
testing.shtml
[66] Usability.gov, Usability Basics,
http://www.usability.gov/basics/index.html
[67] Tewari, H. and O’Mahony, D.: “Multiparty Micropayment for Ad Hoc Network”,
Wireless Communications and Networking, 2003. WCNC 2003. 2003 IEEE, vol.3,
New Orleans, LA, pp 2033-2044.
[68] Ziang, N. and LIU, X. and Zhao, J. and Yang, D.: “A Mobile Micropayment
Protocol Based on Chaos”, 2009 Eighth International Conference on Mobile
Business, pp 284-289.
[69] Pilla, P.: Heuristic Evaluation Report, “Heuristic Evaluation of HOMIE”,
November 29, 2009,
http://www.ccs.neu.edu/home/prasu14/hci/i8/HomieReport.pdf
117
Appendix A: Heuristic Evaluation Heuristic evaluation technique is the most widely used inspection method. This
method is for finding usability issues in a user interface by having a small number of
evaluators (usually one to five) examine the interface and judge its compliance with
usability principles (heuristics).
A.1 A System ChecklistA.1.1 Visibility
The system should always keep user informed about what is going on, through
appropriate feedback within reasonable time.
# Review Checklist Yes No N/A Comments
1.1 Does every display begin with a title or header that describes screen contents? O O O
1.2 Is there a consistent icon design scheme and stylistic treatment across the system? O O O
1.3 Do menu instructions, prompts, and error messages appear in the same place(s) on each menu? O O O
1.4 In multipage data entry screens, is each page labelled to show its relation to others? O O O
1.5 If overtype and insert mode are both available, is there a visible indication of which one the user is in? O O O
1.6 If pop-up windows are used to display error messages, do they allow the user to see the field in error? O O O
1.7 Is there some form of system feedback for every operator action? O O O
1.8 After the user completes an action (or group of actions), does the feedback indicate that the next group of actions can be started? O O O
1.9 Is there visual feedback in menus or dialog boxes about which choices are selectable? O O O
1.10 Is there visual feedback in menus or dialog boxes about which choice the cursor is on now? O O O
1.11 If multiple options can be selected in a menu or dialog box, is there visual feedback about which options are already selected? O O O
1.12 Is there visual feedback when objects are selected or moved? O O O
1.13 Is the current status of an icon clearly indicated? O O O
118
1.14 Does the system provide visibility: that is, by looking, can the user tell the state of the system and the alternatives for action? O O O
1.15 Do GUI menus make obvious which item has been selected? O O O
1.16 Do GUI menus make obvious whether de-selection is possible? O O O
A.1.2 FunctionalityThe system should provide basic functionalities with minimum effort
# Review Checklist Yes No N/A Comments
2.1 Is the number of actions or selections reasonable to complete one main task (e.g. download wallpaper)? O O O
2.2Does the sequence of completing a main task require less or no repetitive scrolling, repetitive selection, and accuracy of selection for completing one main task?
O O O
2.3 Does the interface provide adequate back button functionality to return to a previous screen? O O O
2.4 Is functionality shallow nested requiring a few step selection processes for following links? O O O
2.5 Are there sufficient shortcuts for navigating the activity, function, or action? O O O
A.1.3 User Control and Freedom
Users should be free to select and sequence tasks (when appropriate), rather than
having the system to do this for them. Users often choose system functions by mistake
and will need a clearly marked "emergency exit" to leave the unwanted state without
having to go through an extended dialogue. Users should make their own decisions
(with clear information) regarding the costs of exiting current work. The system should
support undo and redo.
119
# Review Checklist Yes No N/A Comments
3.1 If setting up windows is a low-frequency task, is it particularly easy to remember? O O O
3.2 In systems that use overlapping windows, is it easy for users to rearrange windows on the screen? O O O
3.3 In systems that use overlapping windows, is it easy for users to switch between windows? O O O
3.4 When a user's task is complete, does the system wait for a signal from the user before processing? O O O
3.5 Can users type-ahead in a system with many nested menus? O O O
3.6 Are users prompted to confirm commands that have drastic, destructive consequences? O O O
3.7 Is there an "undo" function at the level of a single action, a data entry, and a complete group of actions? O O O
3.8 Can users cancel out of operations in progress? O O O
3.9 Are character edits allowed in commands? O O O
3.10 Can users reduce data entry time by copying and modifying existing data? O O O
3.11 Are character edits allowed in data entry fields? O O O
3.12 If menu lists are long (more than seven items), can users select an item either by moving the cursor or by typing a mnemonic code? O O O
3.13 If the system uses a pointing device, do users have the option of either clicking on menu items or using a keyboard shortcut? O O O
3.14 Are menus broad (many items on a menu) rather than deep (many menu levels)? O O O
3.15 If the system has multiple menu levels, is there a mechanism that allows users to go back to previous menus? O O O
3.16 If users can go back to a previous menu, can they change their earlier menu choice? O O O
3.17 Can users move forward and backward between fields or dialog box options? O O O
3.18 If the system has multipage data entry screens, can users move backward and forward among all the pages in the set? O O O
3.19 If the system uses a question and answer interface, can users go back to previous questions or skip forward to later questions? O O O
3.20 Do function keys that can cause serious consequences have an undo feature? O O O
120
3.21 Can users easily reverse their actions? O O O
3.22 If the system allows users to reverse their actions, is there a retracing mechanism to allow for multiple undos? O O O
3.23 Can users set their own system, session, file, and screen defaults? O O O
A.1.4 Consistency
Users should not have to wonder whether different words, situations, or actions mean
the same thing. Follow platform conventions.
# Review Checklist Yes No N/A Comments
4.1 Have industry or company formatting standards been followed consistently in all screens within a system? O O O
4.2 Has a heavy use of all uppercase letters on a screen been avoided? O O O
4.3 Do abbreviations not include punctuation? O O O
4.4 Are integers right-justified and real numbers decimal-aligned? O O O
4.5 Are icons labelled? O O O
4.6 Are there no more than twelve to twenty icon types? O O O
4.7 Are there salient visual cues to identify the active window? O O O
4.8 Does each window have a title? O O O
4.9 Are vertical and horizontal scrolling possible in each window? O O O
4.10 Does the menu structure match the task structure? O O O
4.11Have industry or company standards been established for menu design, and are they applied consistently on all menu screens in the system?
O O O
4.12 Are menu choice lists presented vertically? O O O
4.13 If "exit" is a menu choice, does it always appear at the bottom of the list? O O O
4.14 Are menu titles either centered or left-justified? O O O
4.15 Are menu items left-justified, with the item number or mnemonic preceding the name? O O O
4.16 Do embedded field-level prompts appear to the right of the field label? O O O
4.17 Do on-line instructions appear in a consistent location across O O O
121
screens?
4.18 Are field labels and fields distinguished typographically? O O O
4.19 Are field labels consistent from one data entry screen to another? O O O
4.20 Are fields and labels left-justified for alpha lists and right-justified for numeric lists? O O O
A.1.5 Help Users Recover from Errors
Error messages should be expressed in plain language (NO CODES).
# Review Checklist Yes No N/A Comments
5.1 Is sound used to signal an error? O O O
5.2 Are prompts stated constructively, without overt or implied criticism of the user? O O O
5.3 Do prompts imply that the user is in control? O O O
5.4 Are prompts brief and unambiguous? O O O
5.5 Are error messages worded so that the system, not the user, takes the blame? O O O
5.6 If humorous error messages are used, are they appropriate and inoffensive to the user population? O O O
5.7 Are error messages grammatically correct? O O O
5.8 Do error messages avoid the use of exclamation points? O O O
5.9 Do error messages avoid the use of violent or hostile words? O O O
5.10 Do error messages avoid an anthropomorphic tone? O O O
5.11 Do all error messages in the system use consistent grammatical style, form, terminology, and abbreviations? O O O
5.12 Do messages place users in control of the system? O O O
5.13 Does the command language use normal action-object syntax? O O O
5.14 Does the command language avoid arbitrary, non-English use of punctuation, except for symbols that users already know? O O O
5.15 If an error is detected in a data entry field, does the system place the cursor in that field or highlight the error? O O O
5.16 Do error messages inform the user of the error's severity? O O O
5.17 Do error messages suggest the cause of the problem? O O O
122
5.18 Do error messages provide appropriate semantic information? O O O
5.19 Do error messages provide appropriate syntactic information? O O O
5.20 Do error messages indicate what action the user needs to take to correct the error? O O O
5.21 If the system supports both novice and expert users, are multiple levels of error-message detail available? O O O
A.1.6 Error Prevention
Even better than good error messages is a careful design which prevents a problem
from occurring in the first place.
# Review Checklist Yes No N/A Comments
6.1 If the database includes groups of data, can users enter more than one group on a single screen? O O O
6.2 Have dots or underscores been used to indicate field length? O O O
6.3 Is the menu choice name on a higher-level menu used as the menu title of the lower-level menu? O O O
6.4 Are menu choices logical, distinctive, and mutually exclusive? O O O
6.5 Are data inputs case-blind whenever possible? O O O
6.6 If the system displays multiple windows, is navigation between windows simple and visible? O O O
6.7 Are the function keys that can cause the most serious consequences in hard-to-reach positions? O O O
6.8Are the function keys that can cause the most serious consequences located far away from low-consequence and high-use keys?
O O O
6.9 Has the use of qualifier keys been minimized? O O O
6.10 If the system uses qualifier keys, are they used consistently throughout the system? O O O
6.11 Does the system prevent users from making errors whenever possible? O O O
6.12 Does the system warn users if they are about to make a potentially serious error? O O O
6.13 Does the system intelligently interpret variations in user commands? O O O
6.14 Do data entry screens and dialog boxes indicate the number of character spaces available in a field? O O O
123
6.15 Do fields in data entry screens and dialog boxes contain default values when appropriate? O O O
A.1.7 Memorability
Make objects, actions, and options visible. The user should not have to remember
information from one part of the dialogue to another. Instructions for use of the system
should be visible or easily retrievable whenever appropriate.
# Review Checklist Yes No N/A Comments
7.1 Are borders used to identify meaningful groups? O O O
7.2 Does the data display start in the upper-left corner of the screen? O O O
7.3 Are multiword field labels placed horizontally (not stacked vertically)? O O O
7.4 Are all data a user needs on display at each step in a transaction sequence? O O O
7.5 Are prompts, cues, and messages placed where the eye is likely to be looking on the screen? O O O
7.6 Have prompts been formatted using white space, justification, and visual cues for easy scanning? O O O
7.7 Do text areas have "breathing space" around them? O O O
7.8 Is there an obvious visual distinction made between "choose one" menu and "choose many" menus? O O O
7.9 Have spatial relationships between soft function keys (on-screen cues) and keyboard function keys been preserved? O O O
7.10 Does the system gray out or delete labels of currently inactive soft function keys? O O O
7.11 Is white space used to create symmetry and lead the eye in the appropriate direction? O O O
7.12 Have items been grouped into logical zones, and have headings been used to distinguish between zones? O O O
7.13 Have zones been separated by spaces, lines, color, letters, bold titles, rules lines, or shaded areas? O O O
7.14 Are field labels close to fields, but separated by at least one space? O O O
7.15 Are long columnar fields broken up into groups of five, separated by a blank line? O O O
7.16 Are optional data entry fields clearly marked? O O O
124
7.17 Are symbols used to break long input strings into "chunks"? O O O
7.18 Is reverse video or color highlighting used to get the user's attention? O O O
7.19 Is reverse video used to indicate that an item has been selected? O O O
7.20 Are size, boldface, underlining, color, shading, or typography used to show relative quantity or importance of different screen items? O O O
7.21 Are borders used to identify meaningful groups? O O O
7.22 Has the same color been used to group related elements? O O O
7.23 Is color coding consistent throughout the system? O O O
7.24 Is color used in conjunction with some other redundant cue? O O O
7.25 Is there good color and brightness contrast between image and background colors? O O O
7.26 Is the first word of each menu choice the most important? O O O
A.1.8 Flexibility
Accelerators-unseen by the novice user-may often speed up the interaction for the
expert user such that the system can cater to both inexperienced and experienced users.
Allow users to tailor frequent actions. Provide alternative means of access and
operation for users who differ from the "average" user (e.g., physical or cognitive
ability, culture, language, etc.)
# Review Checklist Yes No N/A Comments
8.1 If the system supports both novice and expert users, are multiple levels of error message detail available? O O O
8.2 Does the system allow novices to use a keyword grammar and experts to use a positional grammar? O O O
8.3 Can users define their own synonyms for commands? O O O
8.4Does the system allow novice users to enter the simplest, most common form of each command, and allow expert users to add parameters?
O O O
8.5 Do expert users have the option of entering multiple commands in a single string? O O O
8.6 Does the system provide function keys for high-frequency commands? O O O
8.7 For data entry screens with many fields or in which source O O O
125
documents may be incomplete, can users save a partially filled screen?
8.8 Does the system automatically enter leading zeros? O O O
8.9 If menu lists are short (seven items or fewer), can users select an item by moving the cursor? O O O
8.10 If the system uses a type-ahead strategy, do the menu items have mnemonic codes? O O O
8.11 If the system uses a pointing device, do users have the option of either clicking on fields or using a keyboard shortcut? O O O
8.12 Does the system offer "find next" and "find previous" shortcuts for database searches? O O O
8.13 On data entry screens, do users have the option of either clicking directly on a field or using a keyboard shortcut? O O O
8.14 On menus, do users have the option of either clicking directly on a menu item or using a keyboard shortcut? O O O
8.15 In dialog boxes, do users have the option of either clicking directly on a dialog box option or using a keyboard shortcut? O O O
8.16 Can expert users bypass nested dialog boxes with either type-ahead, user-defined macros, or keyboard shortcuts? O O O
A.1.9 Aesthetic
Dialogues should not contain information which is irrelevant or rarely needed. Every
extra unit of information in a dialogue competes with the relevant units of information
and diminishes their relative visibility.
# Review Checklist Yes No N/A Comments
9.1 Is only (and all) information essential to decision making displayed on the screen? O O O
9.2 Are all icons in a set visually and conceptually distinct? O O O
9.3 Have large objects, bold lines, and simple areas been used to distinguish icons? O O O
9.4 Does each icon stand out from its background? O O O
9.5If the system uses a standard GUI interface where menu sequence has already been specified, do menus adhere to the specification whenever possible?
O O O
9.6 Are meaningful groups of items separated by white space? O O O
9.7 Does each data entry screen have a short, simple, clear, distinctive O O O
126
title?
9.8 Are field labels brief, familiar, and descriptive? O O O
9.9 Are prompts expressed in the affirmative, and do they use the active voice? O O O
9.10 Is each lower-level menu choice associated with only one higher level menu? O O O
9.11 Are menu titles brief, yet long enough to communicate? O O O
9.12 Are there pop-up or pull-down menus within data entry fields that have many, but well-defined, entry options? O O O
A.1.10 Help and documentation
Even though it is better if the system can be used without documentation, it may be
necessary to provide help and documentation. Any such information should be easy to
search, focused on the user’s task, list concrete steps to be carried out, and not be too
large.
# Review Checklist Yes No N/A Comments
10.1 If users are working from hard copy, are the parts of the hard copy that go on-line marked? O O O
10.2 Are on-line instructions visually distinct? O O O
10.3 Do the instructions follow the sequence of user actions? O O O
10.4 If menu choices are ambiguous, does the system provide additional explanatory information when an item is selected? O O O
10.5 Are data entry screens and dialog boxes supported by navigation and completion instructions? O O O
10.6 If menu items are ambiguous, does the system provide additional explanatory information when an item is selected? O O O
10.7 Are there memory aids for commands, either through on-line quick reference or prompting? O O O
10.8 Is the help function visible; for example, a key labelled HELP or a special menu? O O O
10.9Is the help system interface (navigation, presentation, and conversation) consistent with the navigation, presentation, and conversation interfaces of the application it supports?
O O O
10.10 Navigation: Is information easy to find? O O O
10.11 Presentation: Is the visual layout well designed? O O O
127
10.12 Conversation: Is the information accurate, complete, and understandable? O O O
Evaluator: __________________________ Date: __________________________
Occupation: _________________________________________________________
A.2 Problem Summary
# Problem Heuristic
Number
No of
Evaluators
Severity
Ranking
1 No Sharp colour contrast between product
information and its background.
1 2 2
2 No error message is displayed for invalid entries. 5 3 3
3 Multiple options cannot be selected in a menu or
dialog box.
2, 8 1 2
4 Insufficient keyboard shortcuts for navigating
the activity, function, or action.
2 2 2
5 Exit button not provided to exit application from
any screen.
2, 3 3 3
6 Not all integers and decimals right-justified. 4 2 1
7 The price associated with the product doesn’t
show the currency.
4 4 2
8 No sound used to signal an error. 5 2 1
9 No help topics provided. 10 2 3
10 Borders not used to identify meaningful groups. 1,7 2 2
11 Titles are not provided on every page. 1,4 3 2
12 On the login screen the cursor is not active in
customer id field.
4 2 2
128
Appendix B: Usability TestingThe purpose of this questionnaire is to develop sufficient information to assist us in
evaluating our M&E-NetPay system so that we will be in a position to provide further
judgment on usability of M&E-NetPay System.
The information that you provide will be kept confidential and will not be used for any
other purpose.
B.1 QuestionnairePersonal Information
Age:_______________________Gender:_________________________________
Designation:__________________________________________________________
Education Level: Primary/Secondary/Tertiary
B.1.1 Pre-Test Questionnaire
1. Have you ever used mobile/Internet to download files from the web? Yes No
2. How often do you download files from the web?
Daily Weekly Monthly Occasionally
3. Have you spent money on downloading files from the web?
If yes, approximately what is the minimum amount you spent on a file?
Yes No
If yes:______________________________________________________________
129
4. Did you find any difficulties while purchasing files from the web via internet or
mobile phone?
Yes No
If yes, please specify.
_________________________________________________________________
_________________________________________________________________
5. Do you prefer mobile device or Internet for downloading files from the web?
Mobile Internet (ie. Desktop/Laptop)
B.1.2 Post-Test Questionnaire
1. Please use the scale rating from 1-5 to rate how easy or difficult it is to perform the
following task with M&E-NetPay and CORBA-based NetPay systems.
User Task M&E- NetPay System CORBA-based NetPay
System
Very Difficult …Very Easy Very Difficult …Very
Easy
Register with broker 1 2 3 4 5 1 2 3 4 5
Buy E-coins with broker 1 2 3 4 5 1 2 3 4 5
Search for wallpaper on the
wallpaper site1 2 3 4 5 1 2 3 4 5
Download wallpaper 1 2 3 4 5 1 2 3 4 5
Search for ringtone on the Ringtone
site1 2 3 4 5 1 2 3 4 5
Download ringtone 1 2 3 4 5 1 2 3 4 5
Redeem e-coins with broker 1 2 3 4 5 1 2 3 4 5
130
2. Please use the scale rating from 1-5 to rate how favourable or unfavorable are the
following usability features with M&E-NetPay and CORBA-based NetPay systems.
Usability FeaturesM&E- NetPay System CORBA-based NetPay System
Unfavorable …. Favorable Unfavorable …… Favorable
Easy to learn 1 2 3 4 5 1 2 3 4 5
Efficient to use 1 2 3 4 5 1 2 3 4 5
Easy to remember 1 2 3 4 5 1 2 3 4 5
Low error frequency 1 2 3 4 5 1 2 3 4 5
Overall satisfied 1 2 3 4 5 1 2 3 4 5
3. How fast it is to search a particular file using M&E-NetPay system?
Very fast Fast Moderate Slow Very slow
4. How fast it is to search a particular file using CORBA-based NetPay system?
Very fast Fast Moderate Slow Very slow
5. Are you satisfied with the speed of downloading file using M&E-NetPay system?
Satisfied Unsatisfied
6. Do you prefer to access the M&E-NetPay system using mobile phones?
Yes No
7. How do you rate the overall M&E-NetPay system?
Excellent �Very good Satisfactory Poor
131
B.1.3 Comparison Questionnaire
1. Which system do you prefer most for wide use?
M&E-NetPay CORBA-based NetPay
2. Which system has a more fast and efficient search feature?
M&E-NetPay CORBA-based NetPay
3. Which system do you prefer to use for downloading files from the web?
M&E-NetPay CORBA-based NetPay
4. Which system provided the most feature?
M&E-NetPay CORBA-based NetPay
5. Do you have any comments about the systems?
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
132
B.2 User TasksThe user tasks are designed to compare similar features of M&E-NetPay system with
CORBA-based NetPay system. The set of tasks used to compare the functionalities of
the two systems includes:
� Register with broker
� Buy e-coins with broker
� Search for wallpaper/ringtone
� Download wallpaper/ringtone
B.2.1 Register with brokerB.2.1.1. Type the given URL on the web browser: http://pc3548/broker
B.2.1.2. New users click on the “Register Now” link button.
B.2.1.3. Customer registration page will open-up.
B.2.1.4. Type in your personal information and click on “Register”.
B.2.1.5. If typed information is valid you will get a registration successful message
with your customer id.
B.2.1.6. If typed information in invalid you will get a error message. Then go to 4.
Figure A.1: User registers with broker
133
B.2.2 Buy e-coins with brokerB.2.2.1. If you are not on the Login page click on “Login” button.
B.2.2.2. Enter your login details to login.
B.2.2.3. Go to “Buy E-coins” page to buy the amount of e-coins you want.
B.2.2.4. You will get an E-coin id which you will use to purchase items from vendor
sites.
Figure A.2: User buying e-coins with broker
134
B.2.3 Search for wallpaper/ringtoneB.2.3.1. Log onto the Wallpaper site.
Wallpaper URL: http://pc3548/wallpaper
Ringtone URL: : http://pc3548/ringtone
B.2.3.2. Search for a wallpaper from the Wallpaper by using your preferred search
criteria.
B.2.3.3. The searched wallpaper will be displayed on the screen.
B.2.3.4. Follow steps 2.3.1 to 2.3.3 to search for a ringtone.
B.2.4 Download wallpaper/ringtone� To download the wallpaper/ringtone you need to make sure that you are logged
onto the Wallpaper/Ringtone vendor site.
� Click on the download button. The file will be downloaded onto your computer
and the new balance will be displayed.
Figure B.3: Downloading of ringtone from Ringtone site
135
B.3 Usability Features Summary We summarize the participants’ results for M&E-NetPay and CORBA-based NetPay
system based on the five usability features.
Table B.1 Results for M&E-NetPay micropayment system
Participant Ease of Learning
Efficiency of use
Memoribility Error frequency and
severity
Subjective satisfaction
1 5 4 5 5 4
2 4 5 3 5 4
3 5 4 5 5 4
4 4 5 5 5 5
5 4 5 4 4 4
6 5 4 5 5 5
7 5 5 4 5 5
8 5 3 4 4 4
9 5 5 5 5 5
10 5 5 4 4 4
11 5 4 5 5 5
12 4 4 3 4 4
13 5 5 4 5 5
14 5 5 4 5 5
AVERAGE 4.7 4.5 4.3 4.7 4.5
Overall Average: 4.5
136
Table B.2 Results for CORBA-based NetPay micropayment systemParticipant Ease of
LearningEfficiency
of useMemoribility Error
frequency and severity
Subjective satisfaction
1 3 4 3 4 4
2 4 4 3 4 4
3 3 4 4 4 4
4 4 4 3 4 4
5 3 5 4 4 4
6 5 4 3 4 4
7 3 5 3 3 3
8 4 3 3 4 4
9 5 3 4 2 3
10 5 4 3 4 4
11 3 4 5 3 3
12 3 4 4 4 4
13 3 3 4 4 4
14 5 5 4 4 5
AVERAGE 3.8 4.0 3.6 3.7 3.9
Overall Average: 3.8