Study on Operating Systems for Small Devices for Mobile Payments Application 17 Th July, 2009

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Project Report On Study on Operating Systems for Small Devices for Mobile Payments Application

Submitted by: V V Aishwarya B.E IV/IV (01-07-862)

Department of Computer Science and Engineering (CSE) University College of Engineering (Autonomous) Osmania University , Hyderabad- 500004

Summer Internship Project under the Guidance of Dr. V N Sastry Associate Professor Institute for Development and Research in Banking Technology (IDRBT) (Established by Reserve Bank of India) Road No. 1, Castle Hills, Masab Tank, Hyderabad – 500 057.

July 2009

CSE,UCE,OU 1 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

CERTIFICATE

This is to certify that this project on “ Study on Operating Systems for Small Devices for Mobile Payments Application ” submitted by Ms. V V Aishwarya , 01-07-862 of B.E. IV/IV, CSE, University College of Engineering, Osmania University, is a record of Bonafide work done by her under my guidance during the Summer Internship Programme from 21 st May, 2009 to 17 th July, 2009.

Ms. V V Aishwarya has completed the work assigned to her within the limited period of learning and execution. She has successfully completed the project to my satisfaction and it has been observed that the goals set upon at the outset of this endeavor have been worked upon to the best of the student’s abilities and resources. During this period I have observed her to be very sincere, hardworking and coping up with new challenges. I hereby allow this project to be presented for evaluation with my full consent.

Place: Hyderabad Date: 17 th July, 2009

Project Supervisor: Dr. V N Sastry Associate Professor IDRBT

CSE,UCE,OU 2 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

ACKNOWLEDGEMENT

I would like to thank my supervisor, Dr. V N Sastry , who guided me through the project, and helped me sort out all the problems, be it technical or otherwise; and without whose support, the project would not have reached its present state.

I would also like to thank Ms. K Avanthi , Research Associate, IDRBT for her co-operation and support during my Internship period.

I would also like to thank Dr. B. Sambamurthy , Director, IDRBT and Prof. S Ramchandram , Head, Department of Computer Science and Engineering, University College of Engineering (A), Osmania University, Hyderabad for giving me the opportunity to work at IDRBT.

I would also like to thank Mr. S Srinivasa Rao , Associate Professor, Department of Computer Science and Engineering, University College of Engineering (A), Osmania University, Hyderabad for his encouragement.

Place: Hyderabad

Date: 17 th July, 2009

V V Aishwarya

01-07-862

B.E IV/IV,

CSE, UCE, OU

CSE,UCE,OU 3 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

DECLARATION

I declare that the summer training project report entitled, “ Study on Operating Systems for Small Devices for Mobile Payments Application ” is my own work carried out under the supervision of Dr. V N Sastry at Institute for Development and Research in Banking Technology (IDRBT), Hyderabad. I have put in 45 days of attendance with the supervisor at the center.

I further declare that to the best of my knowledge the project report does not contain any part of any work, which has been submitted for the award of any degree either in this institute or in any other university without proper citation.

Place: Hyderabad Date: 17 th July, 2009

V V Aishwarya

01-07-862

B.E IV/IV,

CSE, UCE, OU

CSE,UCE,OU 4 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Abstract

The project entitled “ Study on Operating Systems for Small Devices for Mobile Payments Application ” gives an overview of the concepts and features of Operating Systems, a comparative study of operating systems for small and portable devices namely Symbian OS, Palm OS, TinyOS, JavaOS, SCOSTA and MULTOS, and also gives an insight into the Mobile Payments Architecture for the existing model. This project also explains the proposed model in detail, giving the various scenarios to be considered during mobile payments.

This project aims at the study of the basic concepts and features of Operating Systems together with an overview of the Computer System Components, Goals, Functions, Characteristics, Services, Types and Different Architectures of Operating Systems. It also aims at a comparative study of Operating Systems for Small and Portable Devices namely Symbian OS, Palm OS, TinyOS, JavaOS, SCOSTA and MULTOS based on various attributes. The project’s main objective is to study the various concepts of Smart Card Operating System for Transport Application (SCOSTA) which gives an overview of smart cards and their physical layout together with the objectives, basic data structures, logical file organization and the command library of SCOSTA. The project also aims at the study of the existing model for the mobile payments architecture and explains the process flow for Pull and Push models in mobile payments so as to get a better understanding. The project also aims at developing a new model for mobile payments which gives the entities involved, the assumptions made and the process flows for different scenarios under the Push model.

Chapter 1 gives an introduction to the concepts and features of Operating Systems and an overview of operating systems for small and portable devices like Symbian OS, Palm OS, TinyOS, JavaOS, SCOSTA and MULTOS. It also gives a brief introduction of Mobile Payments and Java 2 Micro Edition which forms the background for the subsequent chapters.

Chapter 2 gives a detailed insight into the comparison of operating systems for small and portable devices. Chapter 3 deals with the structure, architecture, data structure etc of the Smart Card Operating System for Transport Application (SCOSTA). Chapter 4 gives a detailed insight into the Mobile Payments Architecture. Chapter 4 primarily deals with the existing model for mobile payments and focuses on the developments for the proposed model. The document ends with the references and the appendixes relating to the project.

In this report, we have specified the General Concepts of Operating Systems and also made an attempt to compare Operating Systems for Small and Portable Devices like Symbian OS, Palm OS, TinyOS, JavaOS, SCOSTA and MULTOS for various attributes. We studied the SCOSTA Operating System in detail which gave a greater insight about its Architecture, Data Structures, Security Aspects etc. We studied the Components and Stages of various proposed Mobile Payment Architectures and Processes and then proposed Architecture for Mobile Payments PUSH MODEL. We developed and implemented Mobile Payments Application for PUSH MODEL of making a Payment using J2ME (Java 2 Micro Edition) API and Java Servlet API which serves as the User Interface for Mobile Payments Application on the Mobile Phones.

CSE,UCE,OU 5 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Table of Contents

Page No’s

Chapter 1: Introduction 1 1.1 Concepts and Features of an Operating System 1 1.2 Operating Systems for Small and Portable Devices 9 1.3 Mobile Payments 12 1.4 J2ME 21 1.5 Organization of the Project 29

Chapter 2: Comparison of Operating Systems 30 for Small and Portable Devices 2.1 Broad Categories of Comparison 30 2.2 Comparison based on attributes in each broad category 39 2.3 Summary

Chapter 3: SCOSTA 46

Chapter 4: Mobile Payments Architecture 59 4.1 Existing Model 59 4.2 Proposed Model 69

Chapter 5: Conclusion 78

References 79

Appendix A - J2ME API 81

Appendix B – J2ME Application for Making a Payment PUSH MODEL (Making A Payment) 85

CSE,UCE,OU 6 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Chapter 1: Introduction

1.1 Concepts and Features of an Operating System

1.1.a Introduction Operating system (OS) is the software that manages the sharing of resources of a computing device (computer, mobile phone etc). An OS processes raw system data and user input, and responds by allocating and managing tasks and internal system resources as a service to users and programs of the system. OS is the most important program that runs on a computer. Every general purpose computer must have an OS to run other programs. OS provides a software platform on top of which other programs, called “application programs” run. The application programs are written to run on top of particular OS. Choice of OS, therefore, determines to a great extent, the applications that can run on a computer. Most of computer systems come with a preloaded OS. Examples of OS are MSDOS, UNIX, LINUX, WINDOWS, etc.

An Operating System is a • A Resource allocator that manages and allocates resources. • A Control program that controls the execution of user programs and operations of I/O devices • A Kernel – the one program running at all times (all else being application programs).

1.1.b Computer System Components 1. Hardware – provides basic computing resources (CPU, memory, I/O devices). 2. Operating system – controls and coordinates the use of the hardware among the various application programs for the various users. 3. Applications programs – define the ways in which the system resources are used to solve the computing problems of the users (compilers, database systems,video games, business programs). 4. Users (people, machines, other computers).

1.1.c Operating system goals: • Execute user programs and make solving user problems easier. • Make the computer system convenient to use.

CSE,UCE,OU 7 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.1.d Functions of an OS The purpose of an OS is to organize and control hardware and software, e.g. recognizing input from keyboard, sending output to the display screen, keeping track of files and directories on the disk, and controlling peripheral devices such as disk drives and printers. OS allows the device to behave in a flexible but predictable way.

The two major functions of an OS are: i. To manage the hardware and software resources of the system in a computer. The resources include things such as the processor, memory, disk space, etc. On a cell phone, the resources include keypad, screen, address book, phone dialer, battery and network connections. ii. To provide a stable, consistent way for applications to deal with the hardware without having to know all the details of the hardware. For large systems, the OS has greater responsibilities and powers. It is like a traffic cop – it makes sure that different program and users running at the same time do not interfere with each other. The OS is also responsible for Security, ensuring that unauthorized users do not access the system.

Other Functions of an Operating System • Manage BIOS (Basic Input / Output System) • Manage files on secondary storage devices • Manage primary memory (RAM) • Diagnose software and hardware problems • Interface between hardware and software • Perform housekeeping procedures requested by user • 1.1.e Characteristics of an OS • Efficiency • Throughput to measure the amount of work a processor can complete within a certain time period, it has to be high. • Turn-Around Time to measure the time taken from the submission of a request until the system returns the result, it has to be minimized. • Robustness

CSE,UCE,OU 8 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

• Fault Tolerant to measure the ability of an OS to handle S/W or H/W errors. System does not fail due to isolated application or H/W errors, and if it fails, it does so gracefully by minimizing loss of work and preventing damage to the system’s H/W. • Scalability: The ability of an OS to use resources as they are added. • OS can readily adjust its degree of multiprogramming. • It is a particularly important attribute of multiprocessor systems, processing capacity should increase in proportion to the number of processes. • Extensibility: OS will adapt well to new technologies and provide capabilities to extend to perform tasks beyond its original design. • Portability: OS is designed such that it can operate on many H/W configurations. Also, OS is crucial to achieving applications (S/W) portability. • Security: A secure OS prevents users and S/W from accessing services and resources without authorization. • Interactivity: OS allows applications to respond quickly to user actions or events by easy-to-use user interface. • Usability: OS has the potential to serve a significant user base by providing an easy-to-use interface and supporting a large set of user-oriented applications.

1.1.f Operating System Services • Program execution – system capability to load a program into memory and to run it. • I/O operations – since user programs cannot execute I/O operations directly, the operating system must provide some means to perform I/O. It provides access to Input/Output (I/O) devices: Disks, screens, keyboards, mouse, Printers, cameras, speakers, etc. • File-system manipulation – program capability to read, write, create, and delete files. • Communications – exchange of information between processes executing either on the same computer system or on different systems tied together by a network. Communications are generally through shared memory or message passing. • Error detection and response – ensure correct computing by detecting errors in the CPU and memory hardware, in I/O devices, or in user programs. Errors are classified into o Internal and external hardware errors-Memory errors and Device failures o Software errors-Arithmetic overflow, Division by zero and Access to forbidden memory locations • System access: Ease of accessing system resources. • Program development: support for Compilers, editors and debuggers. • Accounting: An OS is responsible for o Collecting statistics o Monitoring performance o Anticipating future enhancements

1.1.g Types of Operating Systems Operating Systems can be generally categorized in six types, on the basis of computers they control and the type of applications they support.

1.1.g.i Real-Time Operating System (RTOS): Real-Time Operating System responds to inputs instantly. This type of operating systems is used to control scientific devices and similar small instruments where memory and resources are crucial. These type of devices have very limited or no end user utilities , so more effort goes into making the OS really memory efficient and fast (less coding), so as to minimize the execution time ,in turn saving on power as well. e.g.: 8086 etc. Such an OS must enable processes to respond immediately to critical events.

CSE,UCE,OU 9 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.1.g.ii Soft Real-Time systems : ensure that real-time tasks execute with high priority, but do not guarantee which, if any of these tasks will complete on time.

1.1.g.iii Hard Real-Time systems : guarantee that all of their tasks complete on time. They are used in Mission-Critical Systems, such as Air Traffic Control, Nuclear Reactor Monitoring, and Military Command and Control.

1.1.g.iv Single user, single tasking: This type of OS is better version of Real time OS, where one user can do effectively one thing at a time, which means that doing more than one thing at a time is difficult in this type of OS. The palm OS in palm handheld computer is an example of single-task OS.

1.1.g.v Single user, multi tasking: It allows more than one program to run concurrently like printing, scanning, word processing etc. e.g. MS Windows and Apple’s Mac OS.

1.1.g.vi Multi-user: It allows two or more users to run programs at the same time. Some OS permit hundreds or even thousands of concurrent users. E.g. UNIX, VMS and Main Frame OS.

1.1.h Different Architectures of OS Architecture can help designers to manage the complexity in OS as it provides many services and support a variety of H/w and S/W resources. This can be done by organizing OS components and specifying the privilege with which each component of OS executes. Types are as follows:

Monolithic Architecture : Every OS component is contained and can directly and efficiently communicate with any other by using function calls.

Layered Architecture : As Operating Systems became larger and more complex, this approach attempts to address by grouping components that perform similar functions into layers. Each layer communicates exclusively with those immediately above and below it. Layered Operating Systems are more modular than monolithic Operating Systems, because the implementation of each layer can be modified without requiring any modification to other layers. Modularity imposes structure and consistency on the OS that often simplifies validation, debugging, and modification. The operating system is divided into a number of layers (levels), each built on top of lower layers. The bottom layer (layer 0), is the hardware; the highest (layer N) is the user interface. With modularity, layers are selected such that each uses functions (operations) and services of only lower-level layers

CSE,UCE,OU 10 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

An OS Layer

Microkernel Architecture : Kernel is the Software that contains the core component of an OS. This architecture provides only a small number of services in an attempt to keep the kernel small and scalable. These services include low-level memory management, inter-process communication, and basic process synchronization to enable processes to cooperate. Most OS components execute outside the kernel with a lower privilege level. It exhibits a high degree of modularity, making them extensible, portable, and scalable. This approach moves as much from the kernel into “user” space. Communication takes place between user modules using message passing. Benefits: - Easier to extend a microkernel - Easier to port the operating system to new architectures - More reliable (less code is running in kernel mode) - More secure

Networked and Distributed OS:

CSE,UCE,OU 11 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Its structure is based on the Client/Server model. It is up to the OS designers who must carefully consider how to manage data and communication among computers. A process can execute on the computer on which it is created or another computer on the network. In Distributed systems, a single OS manages resources on more than one computer system, so it provides the illusion that multiple computers are a single powerful computer. Accordingly, a process can access all of the system’s resources regardless of the process’s location within the system.

1.1.i Common Operating System Components i. Process Management ii. Main Memory Management iii. File Management iv. I/O System Management v. Secondary Management vi. Networking vii. Protection System viii. Command-Interpreter System

1.1.i.i Process Management A process is a program in execution. A process needs certain resources, including CPU time, memory, files, and I/O devices, to accomplish its task. The operating system is responsible for the following activities in connection with process management. • Process creation and deletion. • Process suspension and resumption. • Provision of mechanisms for: process synchronization and process communication

1.1.i.ii Main-Memory Management Memory is a large array of words or bytes, each with its own address. It is a repository of quickly accessible data shared by the CPU and I/O devices. Main memory is a volatile storage device. It loses its contents in the case of system failure. The operating system is responsible for the following activities in connections with memory management: • Keeping track of which parts of memory are currently being used and by whom. • Decide which processes to load when memory space becomes available. • Allocate and deallocate memory space as needed.

1.1.i.iii File Management A file is a collection of related information defined by its creator. Commonly, files represent programs (both source and object forms) and data. The operating system is responsible for the following activities in connections with file management: • File creation and deletion. • Directory creation and deletion. • Support of primitives for manipulating files and directories. • Mapping files onto secondary storage. • File backup on stable (nonvolatile) storage media.

1.1.i.iv I/O System Management The I/O system consists of: • A buffer-caching system • A general device-driver interface • Drivers for specific hardware devices

CSE,UCE,OU 12 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.1.i.v Secondary-Storage Management Since main memory (primary storage) is volatile and too small to accommodate all data and programs permanently, the computer system must provide secondary storage to back up main memory. Most modern computer systems use disks as the principle on-line storage medium, for both programs and data. The operating system is responsible for the following activities in connection with disk management: • Free space management • Storage allocation • Disk scheduling

1.1.i.vi Networking (Distributed Systems) A distributed system is a collection of processors that do not share memory or a clock. Each processor has its own local memory. The processors in the system are connected through a communication network. Communication takes place using a protocol. A distributed system provides user access to various system resources. Access to a shared resource allows: • Computation speed-up • Increased data availability • Enhanced reliability

1.1.i.vii Protection System Protection refers to a mechanism for controlling access by programs, processes, or users to both system and user resources. The protection mechanism must: • Distinguish between authorized and unauthorized usage. • Specify the controls to be imposed. • Provide a means of enforcement.

1.1.i.viii Command-Interpreter System Many commands are given to the operating system by control statements which deal with: • process creation and management • I/O handling • secondary-storage management • main-memory management • file-system access • protection • networking The program that reads and interprets control statements is called variously: • command-line interpreter • shell (in UNIX) Its function is to get and execute the next command statement.

CSE,UCE,OU 13 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.1.j Development of Operating System concepts and features

CSE,UCE,OU 14 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.2 OPERATING SYSTEMS FOR SMALL AND PORTABLE DEVICES (Symbian OS, Palm OS, TinyOS, JavaOS, SCOSTA and MULTOS)

A brief description of operating systems for small and portable devices like Symbian OS, Palm OS, TinyOS, JavaOS, SCOSTA and MULTOS is presented here.

1.2.a Symbian OS Symbian OS from Symbian Ltd. is designed for mobile devices especially smartphones, with associated libraries, user interface frameworks and reference implementations of common tools. Symbian OS has become a standard operating system for smartphones, and is licensed by more than 85 percent of the world's handset manufacturers. Symbian comes in two major flavors: Series 60 and UIQ. Symbian OS is a 32-bit, little-endian operating system, running on different flavors of ARM architecture. Symbian OS supports many different languages / runtimes: Flash Lite, Java ME,P.I.P.S./Open C, Python, Ruby, Symbian C++ and so on. Symbian C++ is the native language of Symbian OS. Symbian OS is a proprietary operating system designed for mobile devices, with associated libraries, user interface, frameworks and reference implementations of common tools, developed by Symbian Ltd. It is a descendant of Psion's EPOC and runs exclusively on ARM processors although a non-productized x86 port exists. Symbian OS, with its roots in Psion Software's EPOC, features pre-emptive multitasking and memory protection, like other operating systems (especially those created for use on desktop computers). EPOC's approach to multitasking was inspired by VMS and is based on asynchronous server-based events. Symbian OS is the leading OS in the "smart mobile device" market.

1.2.b Palm OS Palm OS is a compact operating system initially developed by U.S. Robotics' owned Palm Computing, Inc. for personal digital assistants (PDAs) in 1996. Palm OS is designed for ease of use with a touch screen based graphical user interface. It is provided with a suite of basic applications for personal information management. The Palm OS platform has provided mobile devices with essential business tools, as well as capability to access the Internet or a central corporate database via a wireless connection. Palm OS is now referred to as Garnet OS. Palm offers support for local file encryption and secure encrypted communications. Major handset brands using Palm OS are Palm & Inc.'s Treo series (Treo 650, Tungsten E2). Palm OS is the computer operating system that provides a software platform for the Palm series of handheld personal digital assistants (PDAs) made by Palm Inc. According to Palm, Palm OS was designed from the beginning to fit into a palm-size device of a specific size and with a specific display size. Palm OS uses multitasking, but only one task is for applications. The user uses one application at a time, one application program must finish before the next can be selected. This constraint allows the operating system to devote full attention to the application that is open. The space needed by the system for any application that is running is kept in dynamic, reusable random access memory (RAM). The application and its related database are kept in what is called permanent storage, but here the permanent

CSE,UCE,OU 15 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009 storage is RAM (rather than a hard disk) that cannot be reused as the dynamic RAM can. Palm OS divides an application into runnable code and different types of data elements, such as user interface elements and icons. The data elements can be easily changed without necessarily having to rewrite code. Palm OS comes with these applications built-in: Dates, Address Book, To Do List, Memo Pad, Calculator, and Password Protection. New applications can be written and added using several facilities that accelerate development. Palm OS comes with communication interfaces to infrared transmission devices, TCP/IP (for Web connection through wireless or wireline devices), and, optionally, barcode recognition scanners.

1.2.c TinyOS TinyOS is a flexible, application-specific operating system for sensor networks, which form a core component of ambient intelligence systems. Sensor networks are low cost and low power devices, designed to collect data, do some local computation and transmit partially processed data via radio frequency or Bluetooth. TinyOS has been designed to meet the requirements of sensor networks. TinyOS supports an event-driven concurrency model based on split-phase interfaces, asynchronous events , and deferred computation called tasks . TinyOS is implemented in the NesC language, a C dialect that is imperative at low level and declarative at high level and supports the TinyOS component and concurrency model as well as extensive cross-component optimizations and compile-time race detection. The operating system fits in 178 Bytes of memory. Sensor Nodes are designed to operate with limited resources and power (WSN use batteries as power supply). Sensor networks are often designed for reliable real-time services. Memory and operational capabilities are low as sensing is less resource demanding than computation in conventional OS .Also, power management is very important in WSNs. So, a special purpose OS for Wireless Sensor Networks was designed.

1.2.d JavaOS JavaOS is a small and efficient operating environment developed by JavaSoft that executes Java applications directly on hardware platforms without requiring a host operating system. JavaOS is a small, memory-efficient, fast, and highly portable operating system (OS) that provides direct support for the Java runtime environment, windowing system, networking capabilities, and other features of the Java API. JavaOS 1.0 is currently available for the Intel X86, Sun SPARC, and Strong ARM hardware platforms. JavaOS will also run on the JavaChip family of processors (picoJava, microJava, and UltraJava). These processors are targeted to a range of products including consumer electronics devices, network computers, and network servers. JavaOS promises to be the operating system of choice for network computers (NCs), Personal Digital Assistants (PDAs), and commercial electronics devices. JavaOS can run with as little as 512K of ROM and 256K of RAM in an embedded environment. An entire JavaOS system running on a networked computer requires only 3MB of ROM and 4MB of RAM.

1.2.e SCOSTA SCOSTA stands for a Smart Card Operating System for Transport Application. SCOSTA is a complete implementable Smart Card Operating Systems Standard developed by National Informatics Centre (NIC),Government of India. These standards are absolutely generic and are deployment-ready for all kind of Identity applications like Citizen ID card, PDS card, Election Card, BPL Card, and PAN Card

CSE,UCE,OU 16 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009 etc. SCOSTA is primarily based on ISO-7816 standard and can comply with any international requirements. The SCOSTA describes the minimum support for the application using the Smart Cards. Smart cards are secured electronic devices that are used for keeping data and other information in a way that only "authorized" users are permitted to see or write the data. It is a smart card deployment for Indian driving licenses and vehicle registration certificates. SCOSTA specifications were defined primarily by National Informatics Centre (NIC),Government of India and IIT Kanpur. The SCOSTA specification is largely compliant with the international ISO 7816 standard (parts 4 to 9) for smart cards. The specifications drawn for the operating system, key management system, application and card layout and ISO definitions are mandatory to be complied with and form an integral part of SCOSTA and associated applications. In addition, the cards for use with these applications must comply with the ISO 7816 standard (parts 1 to 3) that detail the electrical, physical, and communication aspects for smart cards. The relevant standards for the contact- less mode of communication are ISO14443 (parts 1 to 4) that detail the electrical characteristics and contact-less protocol for contact-less mode of communication. SCOSTA can be implemented on any microprocessor based smart card. The applications specify the memory requirement for the card.

1.2.f MULTOS MULTOS is a multi-application smart card operating system, that enables a smart card to carry a variety of applications, from chip & pin application for payment to on-card biometric matching for secure ID and ePassport. MULTOS is an open standard whose development is overseen by the MULTOS Consortium - a body compromised of companies which have an interest in the development of the OS and includes smart card and silicon manufacturers, payment card schemes, chip data preparation, card management and personalization system providers, and smart card solution providers. One of the key differences of MULTOS with respect to other types of smart card OS, is that it implements Secure Trusted Environment Provisioning or STEP , which is a patented mechanism by which the manufacture, issuance and dynamic updates of MULTOS smartcards in the field is entirely under the issuer’s control. This control is enforced through the use of a Key Management Authority (KMA). The KMA provides card issuers with cryptographic information required to bind the card to the issuer, initialize the card for use, and generate permission certificates for the loading and deleting of applications under the control of the issuer. MULTOS is the high-security multi-application Operating System defined, specified, implemented and promoted by the members of The MULTOS Consortium. The OS specification is openly licensed by MAOSCO Limited, the consortium company. It has been implemented on a variety of RSA-capable secure microcontroller platforms by multiple Licensees and many different products are available. It offers Multi-application support and requires a Coprocessor for RSA that makes it expensive. MULTOS was founded by a consortium of companies that had a vision of a standard secure smart card operating system, that could be implemented on any silicon chip, and execute any smart card application, be it payment, identity or ticketing in a standard and secure way. The MULTOS operating system was developed by the MAOSCO Consortium. Security and support of several applications on a single smart card were given high priority. Cards that support MULTOS must meet specific hardware security requirements. Similar to the Java™ operating system, MULTOS applications from different providers can be run on one and the same card. It allows additional applications to be loaded to a card already in the field, e.g. via ATMs or the Internet.

CSE,UCE,OU 17 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.3 Mobile Payments

Mobile Payment can be defined as any payment transaction which involves a mobile device. There are a wide range of options available to perform mobile payments due to availability of network technologies.

Mobile Network technologies have evolved from analog based systems to digital based systems and from circuit switching to packet switching technologies. This evolution can be described by different generations of mobile technologies, i.e. first-generation (1G), second-generation (2G), 2.5G and third- generation (3G) technologies.

Mobile Payments is a new and convenient channel for customers to perform payment transactions and is predicted to increase as the number of mobile phone users increases. The use of mobile devices, such as cellular phones and PDAs, to make payments is growing, particularly in Asia and Europe .

As mobile telephony becomes all-pervasive, India has the opportunity to leap-frog from cash transactions directly to mobile payments. An efficient mobile payment system could supplement cheques and other forms of payment. The payment process can be initiated by the person who has bought the services/commodity (called the customer ) or by the person who is selling them (called the beneficiary ) or through a pre-registered third party.

1.3.a Stakeholders i. Consumers ii. Merchants iii. Mobile Network Operators iv. Mobile device manufacturers v. Financial Institutions and banks vi. Software and technology providers vii. Government and Regulators

1.3.a.i Consumer expectations: Personalized service Minimal learning curve Trust, privacy and security Ubiquitous – anywhere, anytime and any currency Low or zero cost of usage Interoperability between different network operators, banks and devices Anonymity of payments like cash Person to person transfers

1.3.a.ii Merchant expectations: • Faster transactions • Low or zero cost in using the system • Integration with existing payment systems • High security

CSE,UCE,OU 18 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

• Being able to customize the service • Real time status of the mobile payment service • Minimum settlement and Payment time

1.3.a.iii Telecom Network Providers expectations: • Generating new income by increase in traffic • Increased Average Revenue Per User (ARPU) and reduced churn (increased loyalty) • Become an attractive partner to content providers

1.3.a.iv Mobile Device Manufacturers expectations: • Large market adoption with embedded mobile payment application • Low time to market • Increase in Average Revenue Per User (ARPU)

1.3.a.v Banks expectations: • Network operator independent solutions • Payment applications designed by the bank • Exceptional branding opportunities for banks • Better volumes in banking – more mobile payments and less cash transactions • Customer loyalty

1.3.a.vi Software and Technology Providers expectations: • Large markets

1.3.a.vii Government and Regulator expectations • Revenue through taxation of mobile payments • Standards • Providing convenience to citizens

1.3.b Roles and Responsibilities

CSE,UCE,OU 19 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Banks Telcos Third Party Payment processors Facilitate Money Exchange ( Inter & KYC and customer history. Ability to External low-cost hosting Intra Bank) through existing Banking use Telcos KYC for financial for interoperable solution Instruments & systems transactions Transac tional services including Full responsibility for fraud Policies enabling audit processing and Audit Trail to be management as per TRAI guidelines. and governance to be maintained framed Fraud management & KYC Distribution net work to be used to Fraud management and Guidelines to be adhered to provide financial services checks Banks to play active role in P2P and External low-cost hosting at Telco cash-cash payments should be explored Ensure compliance guidelines are Setting up of infrastr ucture for enforced undertaking Domestic Money Remittances along with the Bank Policies enabling audit and governance of such a model to be framed.

1.3.c Mobile Payment Characteristics A mobile payment service in order to become acceptable in the market as a mode of payment the following conditions have to be met (Karnouskos and Fokus, 2004):

1.3.c.i Simplicity and Usability : The m-payment application must be user friendly with little or no learning curve to the customer. The customer must also be able to personalize the application to suit his or her convenience.

1.3.c.ii Universality: M-payments service must provide for transactions between one customer to another customer (C2C), or from a business to a customer (B2C) or between businesses (B2B). The coverage should include domestic, regional and global environments. Payments must be possible in terms of both low value micro-payments and high value macro-payments.

1.3.c.iii Interoperability: Development should be based on standards and open technologies that allow one implemented system to interact with other systems.

1.3.c.iv Security, Privacy and Trust: A customer must be able to trust a mobile payment application provider that his or her credit or debit card information may not be misused. Secondly, when these transactions become recorded customer privacy should not be lost in the sense that the credit histories and spending patterns of the customer should not be openly available for public scrutiny. Mobile payments have to be as anonymous as cash transactions. Third, the system should be foolproof, resistant to attacks from hackers and terrorists. This may be provided using public key infrastructure security, biometrics and passwords integrated into the mobile payment solution architectures.

1.3.c.v Cost: The m-payments should not be costlier than existing payment mechanisms to the extent possible. A m-payment solution should compete with other modes of payment in terms of cost and convenience.

CSE,UCE,OU 20 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.3.c.vi Speed: The speed at which m-payments are executed must be acceptable to customers and merchants.

1.3.c.vii Cross border payments: To become widely accepted the m-payment application must be available globally, word-wide.

1.3.d A Generic Architecture for Mobile Payments

This is a simple, illustrative conceptual model that describes the relationship between the major participants in an m-payment scenario. There is the customer and the merchant who would like to use an m-payment service. The M-Payment Application Service Provider (MASP) provides the necessary technical infrastructure (hardware and software) to facilitate m-payments and acts as an intermediary between the financial institutions and mobile network operators. The MASP registers users who would like to avail of the m-payment service. The users (customers and merchants) have to be registered with the MASP prior to using the service. At the time of registration the MASP collects the bank account details (or credit card details) of the customer and merchant as well as their valid digital certificates. The mobile phone numbers of the customer and the merchant are mapped to their respective bank accounts and this mapping is maintained by the MASP. The users are provided with a client m-payment application (mobile wallet) that is either resident on their phones or else in the SIM card. This application may be provided over the air to the users. The mobile wallet will normally interact with the MASP server. A mobile phone user communicates with a merchant and makes an economic transaction (e.g., buying a ticket from an airline over the phone). The merchant obtains the phone number of the customer and initiates the m-payment transaction request stating the amount for which payment is required. The customer confirms the request and authorizes payment. The MASP receives the authorization and verifies the authenticity of the customer. The MASP then debits the customer account and credits the merchant account by interacting with the bank. Once the electronic funds transfer is successful a confirmation message is sent to the customer and the merchant advising them of the debit and credit respectively. The Certifying Authority also shown in Fig. supplies digital certificates for the users in the system to provide security. This model can be extended to handle the interaction between the MASP and the financial system taking into account inter-bank payments and settlement.

CSE,UCE,OU 21 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.3.e Technologies for Mobile Payments The mobile technology landscape provides various possibilities for implementing m-payments. Essentially, a GSM mobile phone may send or receive information (mobile data service) through three possible channels – SMS, USSD or WAP/GPRS. The choice of the channel influences the way m- payment schemes are implemented. Secondly, the m-payment client application may reside on the phone or else it may reside in the subscriber identity module (SIM). We briefly describe NFC technology as another possibility.

1.3.e.i Short Message Service (SMS) This is a text message service that enables short messages (140-160 characters) that can be transmitted from a mobile phone. Short messages are stored and forwarded by SMS centers. SMS messages have a channel of access to phone different from the voice channel (Valcourt, Robert and Beaulieu, 2005). SMS can be used to provide information about the status of one’s account with the bank (informational) or can be used to transmit payment instructions from the phone (transactional).

CSE,UCE,OU 22 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.3.e.ii Unstructured Supplementary Services Data (USSD) Unstructured Supplementary Service Data (USSD) is a technology unique to GSM. It is a capability built into the GSM standard for support of transmitting information over the signaling channels of the GSM network. USSD provides session-based communication, enabling a variety of applications. USSD is session oriented transaction-oriented technology while SMS is a store-and-forward technology. Turnaround response times for interactive applications are shorter for USSD than SMS.

1.3.e.iii WAP/GPRS General Packet Radio Service (GPRS) is a mobile data service available to GSM users. GPRS provides packet-switched data for GSM networks. GPRS enables services such as Wireless Application Protocol (WAP) access, Multimedia Messaging Service (MMS), and for Internet communication services such as email and World Wide Web access in mobile phones.

1.3.e.iv Phone-based Application (J2ME/BREW) The client m-payment application can reside on the mobile phone of the customer. This application can be developed in Java (J2ME) for GSM mobile phones and in Binary Runtime Environment for Wireless (BREW) for CDMA mobile phones. Personalization of the phones can be done over the air (OTA).

1.3.e.v SIM-based Application The subscriber identity module (SIM) used in GSM mobile phones is a smart card i.e., it is a small chip with processing power (intelligence) and memory. The information in the SIM can be protected using cryptographic algorithms and keys. This makes SIM applications relatively more secure than client applications that reside on the mobile phone. Also, whenever the customer acquires a new handset only the SIM card needs to be moved (Card Technology, 2007). If the application is placed on the phone, a new handset has to be personalized again.

1.3.e.vi Near Field Communication (NFC) NFC is the fusion of contactless smartcard (RFID) and a mobile phone. The mobile phone can be used as a contactless card. NFC enabled phones can act as RFID tags or readers. This creates opportunity to make innovative applications especially in ticketing and couponing (Ondrus and Pigneur, 2007). The ‘Pay-Buy Mobile’ project launched by the GSM Association (fourteen mobile operators are part of the initiative) targets 900 million mobile users with a common global approach using NFC (Card Technology Today, 2007).

1.3.e.vii Dual Chip Usually the m-payment application is integrated into the SIM card. Normally, SIM cards are purchased in bulk by telecom companies and then customized for use before sale. If the m-payment application service provider has to write an m-payment application in the SIM card, this has to be done in collaboration with the telecommunications operator (the owner of the SIM). To avoid this, dual chip phones have two slots one for a SIM card (telephony) and another for a payment chip card. Financial institutions prefer this approach as they can exercise full control over the chip and the mobile payment process (Karnouskos and Fokus, 2004). But, customers would have to invest in dual chip mobile devices.

1.3.e.viii Mobile Wallet

CSE,UCE,OU 23 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

A m-payment application software that resides on the mobile phone with details of the customer (and his or her bank account details or credit card information) which allows the customer to make payments using the mobile phone is called as a mobile wallet. Customers can multi-home with several debit or credit payment instruments in a single wallet. Several implementations of wallets that are company-specific are in use globally.

1.3.f Mobile Payment Solutions Mobile payment solutions may be classified according to the type of payment effected, and based on the technology adopted to implement the solution. There are a variety of combinations of these frameworks – technology adopted and mode of payment, a survey of which would constitute a study in itself. There are three different models available for m-payment solutions on the basis of payment (Lim, 2007): i) Bank account based ii) Credit card based iii) Telecommunication company billing based

1.3.f.i Bank Account based M-Payment Banks have several million customers and telecommunication operators also have several million customers. If they both collaborate to provide an m-payment solution it is a win-win situation for both industries. In this model, the bank account is linked to the mobile phone number of the customer. When the customer makes an m-payment transaction with a merchant, the bank account of the customer is debited and the value is credited to the merchant account.

1.3.f.ii Credit Card based M-Payment In the credit card based m-payment model, the credit card number is linked to the mobile phone number of the customer. When the customer makes an m-payment transaction with a merchant, the credit card is charged and the value is credited to the merchant account. Credit card based solutions have the limitation that it is heavily dependent on the level of penetration of credit cards in the country. In India, the number of credit card holders is 15 million (Subramani, 2006). Only this small segment of the population will benefit in the credit card based model. Though limited in scope, there may be high demand within this segment for a payment solution with credit cards and also, may provide high volumes of transactions.

1.3.f.iii Telecommunication Company Billing of M-Payments Customers may make payment to merchants using his or her mobile phone and this may be charged to the mobile phone bills of the customer. The customer then settles the bill with the telecommunication company (Zheng and Chen, 2003). This may be further classified into prepaid airtime (debit) and postpaid subscription (credit).

1.3.g Technologies for mapping mobile number and bank account number Option 1: Banks allow a debit/credit card based on mobile number & expose this API. This option requires all banks to make changes at switch-level and existing bank software and requires direct connectivity to each bank’s switch for the Payment Platform.

CSE,UCE,OU 24 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Option 2: Banks issue a virtual instrument (debit card) that is tied to the mobile number. This option does not require changes at bank’s switch if an existing switch such as NFS(National Financial Switch) /Visa is used and is Inter-operable from day one if there is a common settlement agency.

Option 3: Stored Value (Pre-paid bank a/c for mobile use only).This option is analogous to withdrawing cash. But Customers are unable to access full balance and Current model requires top-up at bank branches/Internet sites.

1.3.h Transport Protocols 1) No Client Software CLEAR-TEXT SMS (GSM / CDMA): It is a Store and forward mechanism with clear-text (visible to all players).This can be transmitted over the air, through short-code provider, Telco, payment platform, or a bank. The Transmission remains in Sent Items folder by default.

USSD – GSM – ONLY: This is a Session-based protocol and can be encrypted at the Telco-end. It requires connectivity from the Telco and also requires a server-based model.

2) Client Software based HTTPS – GPRS / CDMA: It is a Secure channel – limited to high-end phones ( <25%).Network availability isn’t ubiquitous outside metros. It supports client and server models.

SECURE SMS – GSM / CDMA: It can be encrypted with a client application which can run on SIM card or a Handset. It works on 100% of handsets and supports client and server models.

1.3.i Account Storage - Server side or Client side Server based storage: This requires significant secure storage by platform provider and it is difficult for the banks to entrust this to a 3 rd party. The on-going risk of widespread hacking or internal fraud which can occur is a drawback.

Client based storage: This can be done on a SIM card which is a smart card that provides inherent security. Handset clients can also be made secure using this kind of storage.Risk of hacking attack is low i.e., cost of hacking one phone is the same as the cost of hacking a second phone. There are established business processes/, models for 3 rd party providers.

1.3.j Transaction flows 1.3.j.i Intra Bank Transfer Bank connects to Mobile networks via Mobile Banking Application / Service (MBAS) Sender and Receiver perform a registration at Bank MBAS stores card number, or account no and Bank ID Sender specifies a recipient Mobile number / account number and initiates a transfer request MBAS performs checks and forwards the request to the Bank Bank validates the From / To accounts, performs a fund transfer; responds to the sender and the receiver via MBAS Service offerings:

CSE,UCE,OU 25 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

For Bank’s customers only Bank can offer unique services

Transaction processing and settlement where Intra-bank transactions can be settled by the bank itself

1.3.j.2 Inter Bank Transfer MBAS connects to the mobile networks, and connects to a Transaction Switch, which in turn connects to Banks Same Sender / Receiver Registration process Sender (of Bank 1) specifies a recipient Mobile / account number of other bank (Bank 2) and initiates a transfer request Bank 1 validates the From account, performs a debit and returns status to Switch Switch sends the credit leg to Bank 2 Bank 2 validates the credit account, and responds to Switch If invalid “To” account, sends a failure message to Switch Bank 1 reverses the debit, sends out a failure message to Sender Service offerings: Transfer of funds across banks account Purchase / payments Transaction processing and settlement Intra bank transaction settlement by each bank Inter bank settlement reports by Switch for settlement by Settlement Bank / or settlement Agency

CSE,UCE,OU 26 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.3.k Authentication methods Numeric PIN-based : 4-6 digit PIN verification is most commonly used Option 1: Server-based PIN verification-Requires PIN to be sent Option 2: client-based PIN verification-Requires PIN to be stored on client Option 3: Bank PIN vs. Application PIN - Benefit of not transmitting/storing bank PIN Can be combined with one-time use of bank PIN Fingerprint-based- Expected to be mainstream in a few years Fingerprint == identity; PIN == signature

1.3.l Scenario of Use Consumer Scenarios Remote Merchant & Utility Bill Payments-Call centers and on Internet Physical Merchants-Substitute for cash/card Person-to-person-Long-distance remittances Business to consumer disbursements Physical merchants like a “mobile” POS terminal Banks-Turning “trusted agent” mobiles into ATM’s

1.4 J2ME

Sun Microsystems defines J2ME as "a highly optimized Java run-time environment targeting a wide range of consumer products, including pagers, cellular phones, screen-phones, digital set-top boxes and car navigation systems."

Java 2 Micro Edition (J2ME) combines a resource-constrained Java Virtual Machine (JVM) and a set of Java APIs for developing applications for mobile devices. Announced in June 1999 at the JavaOne Developer Conference, J2ME brings the cross-platform functionality of the Java language to

CSE,UCE,OU 27 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009 smaller devices, allowing mobile wireless devices to share applications. With J2ME, Sun has adapted the Java platform for consumer products that incorporate or are based on small computing devices.

1.4.a J2ME Architecture J2ME uses configurations and profiles to customize the Java Runtime Environment (JRE). As a complete JRE, J2ME is comprised of a configuration, which determines the JVM used, and a profile, which defines the application by adding domain-specific classes. The configuration defines the basic run-time environment as a set of core classes and a specific JVM that run on specific types of devices. The profile defines the application; specifically, it adds domain-specific classes to the J2ME configuration to define certain uses for devices.

The following graphic depicts the relationship between the different virtual machines, configurations, and profiles. It also draws a parallel with the J2SE API and its Java virtual machine. While the J2SE virtual machine is generally referred to as a JVM, the J2ME virtual machines, KVM and CVM, are subsets of JVM. Both KVM and CVM can be thought of as a kind of Java virtual machine -- it's just that they are shrunken versions of the J2SE JVM and are specific to J2ME.

J2ME can be divided into three parts, as shown: a configuration, a profile, and optional packages. A configuration contains the JVM (not the traditional JVM, but the cut-down version) and some class libraries; a profile builds on top of these base class libraries by providing a useful set of APIs; and optional packages, are well, an optional set of APIs that the user may or may not use when creating applications. Optional packages are traditionally not packaged by the device manufacturers, and the user has to package and distribute them with the application. The configuration and profile are supplied by the device manufacturers and they embedded them in the devices.

CSE,UCE,OU 28 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.4.a.i Configurations The configuration defines the basic run-time environment as a set of core classes and a specific JVM that run on specific types of devices. Currently, two configurations exist for J2ME:

1.4.a.i.A Connected Limited Device Configuration (CLDC) is used specifically with the KVM for 16- bit or 32-bit devices with limited amounts of memory. This is the configuration (and the virtual machine) used for developing small J2ME applications. Its size limitations make CLDC more interesting and challenging (from a development point of view) than CDC. An example of a small wireless device running small applications is a Palm hand-held computer.

1.4.a.i.B Connected Device Configuration (CDC) is used with the C virtual machine (CVM) and is used for 32-bit architectures requiring more than 2 MB of memory. An example of such a device is a Net TV box.

1.4.a.ii Profiles The profile defines the type of devices supported by the application. Specifically, it adds domain- specific classes to the J2ME configuration to define certain uses for devices. Profiles are built on top of configurations. Two profiles have been defined for J2ME and are built on CLDC: KJava and Mobile Information Device Profile (MIDP). These profiles are geared toward smaller devices. A skeleton profile, the one on which one can create one’s own profile, the Foundation Profile, is available for CDC.

The most popular profile and configuration that Sun provides are the Mobile Information Device Profile (MIDP) and Connected Limited Device Configuration (CLDC), respectively. As the name suggests, CLDC is for devices with limited configurations; for example, devices that have only 128 to 512KB of memory available for Java applications. Consequently, the JVM that it provides is very limited and supports only a small number of traditional Java classes. (This limited JVM is actually called the KVM .) Its counterpart, the Connected Device Configuration (CDC) is for devices with at least 2MB of memory available and supports a more feature-rich JVM (but still not a standard JVM).

CSE,UCE,OU 29 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

The MID profile complements the CLDC configuration very well because it minimizes both the memory and power required for limited devices. It provides the basic API that is used for creating application for these devices. For example, it provides the javax.microedition.lcdui package that allows one to create the GUI elements that can be shown on a (limited) device running the MID profile on top of a CLDC configuration. Note that MIDP cannot be used with CDC devices. CDC devices get their own set of profiles, like the Foundation and Personal profiles. The latest versions of MIDP and CLDC are 2.0 and 1.1, respectively.

1.4.b Devices J2ME targets Target devices for J2ME applications developed using CLDC generally have the following characteristics: • 160 to 512 kilobytes of total memory available for the Java platform • Limited power, often battery powered • Network connectivity, often with a wireless, inconsistent connection and with limited bandwidth • User interfaces with varying degrees of sophistication; sometimes with no interface at all Some devices supported by CLDC include wireless phones, pagers, mainstream personal digital assistants (PDAs), and small retail payment terminals.

According to Sun Microsystems, target devices for CDC generally have the following characteristics: • Powered by a 32-bit processor • Two megabytes or more of total memory available for the Java platform • Devices that require the full functionality of the Java 2 "Blue Book" virtual machine • Network connectivity, often with a wireless, inconsistent connection and with limited bandwidth • User interfaces with varying degrees of sophistication; sometimes with no interface • Some devices supported by CDC include residential gateways, smartphones and communicators, PDAs, organizers, home appliances, point-of-sale terminals, and car navigation systems.

1.4.c Example – Developing a J2ME Application (MIDlet) This section deals with the aspects of how to install the development tools, how to write the first Java ME application, how to build it, and how to test the application in an emulator. The application, a MIDlet , runs on implementations of the Mobile Information Device Profile, one of the Java ME specifications.

1.4.c.i MIDlet A MIDlet is a Java application framework for the Mobile Information Device Profile (MIDP) that is typically implemented on a Java-enabled cell phone or other embedded device or emulator. MIDlets are applications, such as games.

MIDlet distributions main file is a .jar file, but MIDlet distributions can also consist of a .jad file containing the location of and describing the contents of the .jar file. The implementation of a MIDlet may or may not require the presence of a .jad file.

A MIDlet has to fulfill the following requirements in order to run on a mobile phone: • The main class needs to be a subclass of javax.microedition.midlet.MIDlet • The MIDlet needs to be packed inside a .jar file (e.g. by using the jar-tool) • The .jar file needs to be pre-verified by using a preverifier.

CSE,UCE,OU 30 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

• In some cases, the .jar file needs to be signed by the mobile phone's carrier.

Unlike a Java applet, a MIDlet is limited to use of the LCDUI rather than the more familiar widgets of AWT and Swing. There are many other aspects of the MIDP platform that MIDlet programmers have to take into account. Getting started with developing applications (henceforth called "MIDlets") for the J2ME platform is easy. Although device manufacturers install and prepackage their devices with this JVM (and associated APIs), the user has to install the J2ME Wireless Toolkit 2.2 on the development machine. However, the machine must also have the Java Development Kit (JDK), version 1.4.2 or higher, installed.

1.4.c.ii The MIDlet LifeCycle Mobile devices, whether emulators or real, interact with a MIDlet using their own software, which is called Application Management Software (AMS). The AMS is responsible for initializing, starting, pausing, resuming, and destroying a MIDlet. (Besides these services, AMS may be responsible for installing and removing a MIDlet, as well.) To facilitate this management, a MIDlet can be in one of three states which is controlled via the MIDlet class methods, that every MIDlet extends and overrides. These states are active, paused and destroyed.

An installed MIDlet is put into a paused state by the AMS creating an instance of it, by calling its no-args constructor. This is of course, not the only way that the MIDlet can be in a paused state. It can enter this state when the AMS calls the pauseApp() method on an active MIDlet (and the method returns successfully). It can also enter this state when the MIDlet pauses itself by calling the notifyPaused() method, as opposed to the pauseApp() method, which is called by the AMS.

In a paused state, the MIDlet is waiting for a chance to get into the active state. Theoretically, in this state, it should not be holding or using any of the device resources and should be passive in nature. Once the MIDlet is created, this is the state to be in before becoming active. Also, entering the paused state is necessary when the device requires it to consume fewer resources, because these resources may be required for handling other device functions, like handling an incoming call. This is when the device invokes the pauseApp() method through the AMS. If the MIDlet should inform the AMS that it has

CSE,UCE,OU 31 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009 paused, it should invoke the notifyPaused() method, which tells the AMS that the MIDlet has indeed paused.

One final way in which a MIDlet can get into a paused state is when the MIDlet's startApp() method, which is called when the AMS invokes it to start the MIDlet (either the first time or from a paused state), throws a MIDletStateChangeException. Essentially, in case of an error, the MIDlet takes the safe road of staying in the paused state.

The active state is where every MIDlet wants to be! This is when the MIDlet can do its functions, hold the device resources and generally, do what it is supposed to do. As said previously, a MIDlet is in an active state when the AMS calls the startApp() method on a paused MIDlet (actually, the MIDlet enters the active state just before this method is called by the AMS). A paused MIDlet can request to go into the active state by calling the method resumeRequest(), which informs the AMS that the MIDlet wishes to become active. The AMS may of course, choose to ignore this request or, alternatively, queue it if there are other MIDlets requesting the same.

The destroyed state is entered when a MIDlet's destroyApp(boolean unconditional) method is called and returns successfully, either from an active or paused state. This method is called by the AMS when it feels that there is no need for the MIDlet to keep running and is the place the MIDlet may perform cleanup and other last minute activities. The MIDlet can enter this state itself, by calling the notifyDestroyed() method, which informs the AMS that the MIDlet has cleaned up its resources and is eligible for destruction. Of course, since in this case, the destroyApp(boolean unconditional) method is not called by the AMS, any last-minute activities must be done before this method is invoked.

If the AMS calls the destroyApp(boolean unconditional) method in the middle of an important step that the MIDlet may be doing, and may be loath to be destroyed, then the Boolean unconditional flag comes into the picture. If this flag is set to true, the MIDlet will be destroyed, irrespective of what the MIDlet is doing. However, if this flag is false, effectively, the AMS is telling the MIDlet that it wants the MIDlet to be destroyed, but if the MIDlet is doing something important, it can raise a MIDletStateChangeException, and the AMS will not destroy it just yet. However, note that even then, there are no guarantees that the MIDlet will not be destroyed, and it remains up to each device to decide how they should handle the request. If the device does honor the MIDlet's request, it may try and invoke the destroyApp(boolean unconditional) at a later stage.

Destroyed state means that the MIDlet instance has been destroyed, but not uninstalled from the device. The MIDlet remains installed in the device, and a new instance of it may be created later.

1.4.c.iii Requirements To develop a J2ME application or a MIDlet, the following are required. The Java 2 SDK (formerly known as a JDK); J2SE 1.3 SDK is recommended. In particular, the following tools from the Java 2 SDK will be used: java javac jar

CSE,UCE,OU 32 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

javadoc (optional)

* The Connected Limited Device Configuration (CLDC) reference implementation * The K virtual machine (KVM), which is included with the CLDC reference implementation * The Mobile Information Device Profile (MIDP)

1.4.c.iv CLDC requirements CLDC defines the following requirements: * Full Java language support (except for floating pointer support, finalization, and error handling) * Full JVM support * Security for CLDC * Limited internationalization support * Inherited classes -- all classes not specific to CLDC must be subsets of J2SE 1.3 classes * Classes specific to CLDC are in javax.microedition package and subpackages In addition to the javax.microedition package, the CLDC API consists of subsets of the J2SE java.io, java.lang, and java.util packages.

1.4.c.v MIDP MIDP is geared toward mobile devices such as cellular phones and pagers. The MIDP, is built upon CLDC and provides a standard run-time environment that allows new applications and services to be deployed dynamically on end-user devices. MIDP is a common, industry-standard profile for mobile devices that is not dependent on a specific vendor. It is a complete and supported foundation for mobile application development. MIDP contains the following packages, the first three of which are core CLDC packages, plus three MIDP-specific packages. We will discuss each of these packages later on in the tutorial: java.lang java.io java.util javax.microedition.io javax.microedition.lcdui javax.microedition.midlet javax.microedition.rms

1.4.c.vi MIDP packages In addition to the standard CLDC packages, MIDP also includes three additional packages: * javax.microedition.lcdui -- Defines classes that provide for control over the UI. This package includes both the high-level UI classes (such as Form, Command, DateField, TextField and more), as well as the low-level UI classes (allowing low-level control over the UI). * javax.microedition.midlet -- Contains one of the main MIDP classes, the MIDlet class, which provides MIDP applications access to information about the environment in which they are running. * javax.microedition.rms -- Defines a set of classes that provide a mechanism for MIDlets to persistently store, and later retrieve, data.

1.4.c.vii Downloading and installing the J2ME Wireless Toolkit

CSE,UCE,OU 33 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

The J2ME Wireless Toolkit provides a complete development environment to write and test MIDP applications. The download includes tools, documentation, an emulation environment, examples, and a module to integrate with Forte for Java. Currently, the J2ME Wireless Toolkit is available for Windows 98 Second Edition, Windows NT 4.0, and Windows 2000 only. Windows 95 is not supported.

1.4.c.viii The HelloWorld MIDlet The following MIDlet displays, "Hello World!" on the screen of an MIDP device, as well as an Exit button, which terminates the application when pressed. The HelloWorld.java file starts with the following lines of code to import the classes that will be used later in the HelloWorld class: import javax.microedition.midlet.MIDlet; import javax.microedition.lcdui.Command; import javax.microedition.lcdui.CommandListener; import javax.microedition.lcdui.Display; import javax.microedition.lcdui.Displayable; import javax.microedition.lcdui.Form;

The HelloWorld class extends MIDlet since it is an MIDP application. It also implements CommandListener interface to handle events: public class HelloWorld extends MIDlet implements CommandListener

The following method is the default constructor, which creates a new form, initializes the controls on it, and then displays it: private Form form; public HelloWorld() { // Create a new form on which to display our text form = new Form("Test App"); // Add the text "Hello World!" to the form form.append("Hello World!"); // Add a command button labeled "Exit" form.addCommand( new Command( "Exit", Command.EXIT, 1 ) ); // Register this object as a commandListener form.setCommandListener( this ); } The startApp() method is invoked to start the application much like an applet's start method. It may be called numerous times during a single execution of a MIDlet. If the MIDlet is paused, pauseApp() will be invoked. To restart the MIDlet, startApp() will be called. Main initialization code that needs to be performed only once should be placed in the constructor: public void startApp() {

CSE,UCE,OU 34 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

// Get a reference to the display, and show the form Display display = Display.getDisplay(this); display.setCurrent( form ); } pauseApp() is invoked to put the MIDlet into a paused state. However pauseApp must be implemented in the MIDlet because it is an abstract method in the parent MIDlet class. public void pauseApp() { } destroyApp() is invoked to destroy the MIDlet and put it into a destroyed state. public void destroyApp(boolean unconditional) { form = null; }

The commandAction() method is the event handler required to implement the CommandListener interface. Currently it destroys the application, and notifies the application management software that the MIDlet is complete. public void commandAction(Command c, Displayable d) { // Destroy this MIDlet destroyApp(true); // Notify the application management software that this MIDlet // has entered the destroyed state notifyDestroyed(); }

1.4.d Summary A MIDlet is a Java class that extends the javax.microedition.midlet.MIDlet abstract class. It implements the startApp(), pauseApp(), and destroyApp() methods, which one can think of as being similar to J2SE's start(), stop(), and destroy() methods in the java.applet.Applet class.

In addition to the primary MIDlet class that extends javax.microedition.midlet.MIDlet, an MIDP application usually includes other classes, which can be packaged as jar files along with their resources -- this is known as a MIDlet suite . The various MIDlets in a MIDlet suite can share the resources of the jar file, although MIDlets from different suites cannot directly interact.

A MIDlet exists in one of three possible states during the application life cycle -- active, paused, or destroyed. Active state , as the name implies, means the MIDlet is running. This state begins when the startApp method is called. In a paused state , all resources the MIDlet is holding are released, but it is prepared to be activated again. The notifyPaused method invokes the paused state. In the destroyed state , a MIDlet has permanently shut itself down, releasing all resources, and is awaiting the garbage collector. It is invoked with the notifyDestroyed method.

CSE,UCE,OU 35 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1.5 Organization of the Project

In this chapter, we have presented the concepts and features of operating systems and we have given an overview of operating systems for small and portable devices like Symbian OS, Palm OS, TinyOS, JavaOS, SCOSTA and MULTOS. We have also given a brief introduction of Mobile Payments and Java 2 Micro Edition which forms the background for the subsequent chapters.

Chapter 2: COMPARISON OF OPERATING SYSTEMS FOR SMALL AND PORTABLE DEVICES

CSE,UCE,OU 36 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

2.1 Broad Categories of Comparison

A comparison of operating systems for small and portable devices namely, Symbian OS, Palm OS, TinyOS, JavaOS, SCOSTA and MULTOS has been made in this chapter. The comparison is based the following broad categories:

A. Aims/Goals B. Design Principles C. Features D. Architecture E. Security F. Applications

The attributes corresponding to each of the above broad categories have been described in this section and the operating systems have been compared in section 2.2.

2.1.A AIMS / GOALS

CSE,UCE,OU 37 IDRBT

Attributes Description Robustness A software is robust if it continues to operate despite abnormalities in input, th Study on Operating Systemscalculations, for Small etc. Devices for Mobile Payments Application 17 July, 2009 Concurrency Concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors. Efficiency It refers to optimizing the speed and memory requirements of a computer program. Efficiency is used to describe properties of an algorithm relating to how much of various types of resources it consumes. Modularity It is the degree to which an article or system is made up of relatively independent but interlocking components or parts. Software module is the unit of deployment and configuration. Modularity can have variable granularity. It encourages code-reuse and software quality can be improved by localizing the effects of design and implementation changes. Modularity helps in Data encapsulation. Standardization It is the formulation, publication, and implementation of guidelines, rules, and specifications for common and repeated use, aimed at achieving optimum degree of order or uniformity in a given context, discipline, or field. Simplicity The software should be simple to learn and convenient to understand by the user. Low Power The system should consume as much less (battery) power as possible. Overhead Portability It is the ability of a software to run (with little or no modification) on different hardware and/or software platforms, or work with different versions of the same hardware or program. In general, software written in Java has this ability. Low System There should be low system overhead i.e., less load on the processor to gain Overhead throughput and thus the efficiency Speed The system should be fast in responding to the user’s requests ensuring convenience to the user. Dynamic It is the capability of changing or being changed; not static Security Security is the degree of protection against danger, loss, and criminals.The system should ensure security. A form of protection where a separation is created between the assets and the threat. This includes but is not limited to the elimination of either the asset or the threat. In order to be secure, either the asset is physically removed from the threat or the threat is physically removed from the asset. Quick In batch processing, the time it takes to receive finished reports after Turnaround Time submission of documents or files for processing. In an online environment, turnaround time is the same as response time. In half-duplex transmission, the time it takes to change from transmit to receive and vice versa. Easy The system should be capable of being accomplished or acquired with ease posing no difficulty. Small Memory Memory footprint refers to the amount of main memory that a program uses Footprint or references while running.The Operating system should have small memory footprint for good performance. Multiple Refers to two or more operating environments, which typically include the Platforms CPU family and operating system. For example, if versions of a program run CSE,UCE,OU on Windows and the Macintosh,38 the software is said to support multipleIDRBT platforms. That application is also known as a "cross platform" application. Integrity The quality of correctness, completeness, wholeness, soundness and compliance with the intention of the creators of the data. It is achieved by preventing accidental or d eliberate but unauthorized insertion, modification or Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

2.1.B DESIGN PRINCIPLES

Attributes Description Interoperability Interoperability is a property referring to the ability of diverse systems and organizations to work together (inter-operate). Interoperability is the transfer and use of information in a uniform and efficient manner across multiple organisations and IT systems. Its purpose is to create a shared understanding of data. Reusability Reusability is the segment of source code that can be used again to add new functionalities with slight or no modification. Reusable modules and classes reduce implementation time, increase the likelihood that prior testing and use has eliminated bugs and localizes code modifications when a change in implementation is required. Flexibility It is defined as the adaptation of the system to the external changes. Flexibility in terms of operating systems refers to the point that there is no predefined kernel functionality. Concurrency Concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors. Low System /Power The system should consume as much less (battery) power as Overhead possible. There should be low system overhead i.e., less load on the processor to gain throughput and thus the efficiency Ubiquitous use of servers Resources are generally under the control of the servers; if the kernel itself is a server, it also includes kernel-owned resources. So all these resources have to be properly utilized. Standardization It is the formulation, publication, and implementation of guidelines, rules, and specifications for common and repeated use, aimed at achieving optimum degree of order or uniformity in a given context, discipline, or field. Ease the development The system will ease the development of a variety of applications Limited Resources Resources are limited and thus there should be proper scheduling mechanism that results in good performance of the system Pervasive Asynchronous all resources are available to multiple simultaneous clients; in other Services words, it is a service request and callback model rather than a blocking model Event-centric Events are treated as the main parts for ensuring interactivity to the users. The system should support interactivity through events and also provide the necessary functionality for handling them.

CSE,UCE,OU 39 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Low Duty Cycle The duty cycle operations should be low. Operations Extensibility Extensibility (forward compatibility) is a system design principle where the implementation takes into consideration the future growth.There should be a possibility to assemble essential Embedded OS services at compile time. Other EOS and application services can be dynamically loaded at runtime. There should be an Abstract Hardware Layer (AHL) that separate language and hardware architecture. AHL should also provide direct and safe access to hardware Support for availability The Operating System or the software should be easily and conveniently available to the users. Portability Portability is the general characteristic of being readily transportable from one location to another Non-Proprietary not protected by trademark or patent or copyright; "nonproprietary products are in the public domain and anyone can produce or distribute them" Security and Integrity Security is the degree of protection against danger, loss, and criminals.The system should ensure security. A form of protection where a separation is created between the assets and the threat. This includes but is not limited to the elimination of either the asset or the threat. In order to be secure, either the asset is physically removed from the threat or the threat is physically removed from the asset. The quality of correctness, completeness, wholeness, soundness and compliance with the intention of the creators of the data. It is achieved by preventing accidental or deliberate but unauthorized insertion, modification or destruction of data in a database. Data integrity is one of the six fundamental components of information security Modularity It is the degree to which an article or system is made up of relatively independent but interlocking components or parts . Software module is the unit of deployment and configuration. Modularity can have variable granularity. It encourages code-reuse and software quality can be improved by localizing the effects of design and implementation changes. Modularity helps in Data encapsulation. Separation of user The User Interface should be separated from the various services interfaces from services offered by the Operating System for improving the performance and for reducing the burden on the Operating System. Open Standards An open standard is a standard that is publicly available and has various rights to use associated with it, and may also have various properties of how it was designed Compatibility It is the capability of being used together without special modification or adaptation.

CSE,UCE,OU 40 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

2.1.C FEATURES

Attributes Description Object- Object-oriented programming ( OOP ) is a programming paradigm that uses Oriented "objects" — data structures consisting of datafields and methods — and their interactions to design applications and computer programs. Programming techniques may include features such as information hiding, data abstraction, encapsulation, modularity, polymorphism, and inheritance. Kernel The kernel is a program that constitutes the central core of a computer operating system. It has complete control over everything that occurs in the system. Deletion of Applications can be securely deleted and others added over the lifetime of a card application without the card ever leaving the cardholder’s possession. over lifetime of a card Certification A certificate authority or certification authority ( CA ) is an entity that issues Authority digital certificates for use by other parties. It is an example of a trusted third party. CAs are characteristic of many public key infrastructure (PKI) schemes. Memory Memory management is the act of managing computer memory. This involves Management providing ways to allocate portions of memory to programs at their request, and freeing it for reuse when no longer needed. The management of main memory is critical to the computer system. Interrupt An interrupt is an asynchronous signal indicating the need for attention or a Driven synchronous event in software indicating the need for a change in execution. Interrupts are a commonly used technique for computer multitasking, especially in real-time computing. Such a system is said to be interrupt-driven. Easy to use A software should be easy to learn and use Reusable pieces of software that can be used in other programs Components Efficient able to accomplish a purpose; functioning effectively without wasting resources Dynamic Applications can be securely “downloaded” (added) to the card either in a bureau Remote or physical customer services location (e.g. a bank branch) or remotely over Loading insecure networks (i.e. by going on-line to the issuer via a telephone, ATM, or via a PC across the Internet). Multimedia Multimedia relates to an application that can combine text, graphics, full-motion video, and sound into an integrated package. Event-Driven Event-driven programming or event-based programming is a programming Model paradigm in which the flow of the program is determined by events—i.e., sensor outputs or user actions (mouse clicks, key presses) or messages from other programs or threads.

CSE,UCE,OU 41 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

File The term computer file management refers to the manipulation of documents Management and data in a computer Generic Relating to or descriptive of an entire group or class; general Dynamic The applications running on top of the Operating System should be managed Application dynamically by the OS itself to allow enhanced interactivity with the users. Management Scheduling Scheduling is the process of deciding how to commit resources between a wide variety of possible tasks. Process Process management is the ensemble of activities of planning and monitoring Management the performance of a process. Cross Platform Refers to developing software for, or running software on, more than one type of Development hardware platform. The most universal cross platform application is the Web browser. Written for every desktop computer platform, Web browsers render Web pages "almost" the same no matter which computer they run on Networking Computer networking is the engineering discipline concerned with communication between computer systems or devices. Good The Operating System should promise good performance to its users by means Performance of proper scheduling, memory, file and disk management, better throughput and response times. Exceptional Exception handling is a programming language construct or computer hardware Handling mechanism designed to handle the occurrence of exceptions - special conditions that change the normal flow of execution. Robust Robust Business Model is one which does not fail as a whole in the event of Business failures. Model Multitasking/M Multitasking is a method by which multiple tasks, also known as processes, ultithreading share common processing resources such as a CPU. Multithreading computers have hardware support to efficiently execute multiple threads. Component Components can be files, modules etc. Such components form the basic building Programming blocks of the Operating System in a Component Programming Model. Model Small Memory Memory footprint refers to the amount of main memory that a program uses or Footprint references while running. The Operating system should have small memory footprint for good performance. GUI Graphical User Interface Security Security is the degree of protection against danger, loss, and criminals.The system should ensure security. A form of protection where a separation is created between the assets and the threat. This includes but is not limited to the elimination of either the asset or the threat. In order to be secure, either the asset is physically removed from the threat or the threat is physically removed from the asset. Desktop Synchronizing the various applications running on the desktop. Synchronizatio

CSE,UCE,OU 42 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

n Multi- The Operating System should have support for multiple applications. application Support Maturity Maturity here refers to the maturity level of security. Data It is the process of managing data as a resource. It is also the process of Management developing data architectures, practices and procedures dealing with data and then executing these aspects on a regular basis.

2.1.D ARCHITECTURE

Attributes Description Layered As Operating Systems became larger and more complex, this approach attempts Architecture to address by grouping components that perform similar functions into layers. Each layer communicates exclusively with those immediately above and below it. Layered Operating Systems are more modular than monolithic Operating Systems, because the implementation of each layer can be modified without requiring any modification to other layers. Modularity imposes structure and consistency on the OS that often simplifies validation, debugging, and modification. Support for A microkernel is a computer kernel that provides the mechanisms needed to Microkernel implement an operating system, such as low-level address space management, thread management, and inter-process communication. Hardware A hardware abstraction layer ( HAL ) is an abstraction layer, implemented in Abstraction software, between the physical hardware of a computer and the software that Layer runs on that computer. Its function is to hide differences in hardware from most of the operating system kernel, so that most of the kernel-mode code does not need to be changed to run on systems with different hardware. On a PC, HAL can basically be considered to be the driver for the motherboard and allows instructions from higher level computer languages to communicate with lower level components, such as directly with hardware. Device Drivers A device driver or software driver is a computer program allowing higher- level computer programs to interact with a hardware device. A driver typically communicates with the device through the computer bus or communications subsystem to which the hardware is connected. Separate The Operating Systems which support networking can also have a separate Network Layer Network Layer so as to reduce the burden on the Operating System. Presence of a A virtual machine (VM) is a software implementation of a machine (computer) Virtual that executes programs like a real machine. Machine User Interface User Interface is the interface through which the user interacts with the system. Integration Every Operating System should be easily integrated with any hardware, i.e.

CSE,UCE,OU 43 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

with Hardware support portability.

2.1.E SECURITY

Attributes Description Signed Certificate A signed certificate is an identity certificate that is signed by a person Limited Memory Memory should be protected from malicious software and also unauthorized Safety users. If this does not happen, the system has limited memory safety and all the important data will be corrupted. Security A security environment (SE) is a logical container having security Environment components required either for the security mechanism of the card or for secure messaging. Data This mechanism provides confidentiality by data encryption and decryption Confidentiality so that only the genuine key holders are able to see data. Data Integrity This mechanism deals with the computation of message authentication code (MAC) or hash. For different messages it is almost impossible to generate same MAC hence it is used to detect alteration in messages. Biometrics Biometrics refers to methods for uniquely recognizing humans based upon one or more intrinsic physical or behavioral traits. Data Caging Data caging means that the applications and the users have access only to certain areas of the file system. Greater Memory Memory should be protected from malicious software and also unauthorized Safety / Security users. If this does not happen, the system has limited memory safety and all the important data will be corrupted. Support for Cryptography or cryptology is the practice and study of hiding Cryptography information. Applications of cryptography include ATM cards, computer passwords, and electronic commerce. Secure Messaging This mechanism is used for secure transmission of commands and responses. This secure transmission is achieved by confidentiality and integrity over command and response. Security Security architecture gives the organization of various components that work Architecture together for ensuring security. Support for Security is an important feature for Operating Systems to protect all its Security Model resources from unauthorized software and users. Some models are available for ensuring security.

2.1.F APPLICATIONS

Attributes Description Mobile Phones A mobile phone or mobile (also called cellphone and handphone , as well as cell phone , wireless phone , cellular phone , cell , cellular telephone , mobile

CSE,UCE,OU 44 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

telephone or cell telephone ) is a long-range, electronic device used for mobile voice or data communication over a network of specialized base stations known as cell sites. Wireless Sensor WSN is a computer network composed of many, spatially distributed small Networks devices that use sensors to monitor environment at different locations. Sensor networks are low cost and low power devices, designed to collect data, do some local computation and transmit partially processed data via radio frequency or Bluetooth. Sensor Nodes are designed to operate with limited resources and power (WSN use batteries as power supply). Sensor networks are often designed for reliable real-time time services. Embedded An embedded system is a special-purpose computer system designed to Devices/ Systems perform one or a few dedicated functions, often with real-time computing constraints. It is usually embedded as part of a complete device including hardware and mechanical parts. In contrast, a general-purpose computer, such as a personal computer, can do many different tasks depending on programming. Embedded systems control many of the common devices in use today. Network Access Network Access Control (NAC) is an approach to computer network security Control that attempts to unify endpoint security technology (such as antivirus, host intrusion prevention, and vulnerability assessment), user or system authentication and network security enforcement. Identity Cards Identity cards contain numbers that uniquely identify a person or institution. Embedded Robotics is the science and technology of robots, their design, manufacture, Robotics and application. e-passports Passports available through cards or over the internet. PDAs Personal Digital Assistants Network Network Computer (often abbreviated NC ) is a trademark of Oracle Computers Corporation that was used, from approximately 1996 to 2000, to market a range of diskless desktop computer devices. The devices were designed and manufactured by an alliance, which included Sun Microsystems, IBM, and others. ATMs Automated Teller Machines Electronic An electronic component is any physical entity in an electronic system whose Devices intention is to affect the electrons or their associated fields in a desired manner consistent with the intended function of the electronic system. Components are generally intended to be connected together, usually by being soldered to a printed circuit board (PCB), to create an electronic circuit with a particular function (for example an amplifier, radio receiver, or oscillator). Components may be packaged singly or in more complex groups as integrated circuits. Some common electronic components are capacitors, resistors, diodes, transistors, etc. Payments Payments refer to the transfer of funds between two parties. Sensor Actuator Sensor Actuator Networks have both sensors (set the state of the environment) Networks and actuators (report the state of the environment).

CSE,UCE,OU 45 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Military Applications that can be used in military. Applications

2.2 COMPARISON based on attributes in each category

Comparison of Operating Systems for small and portable devices namely, Symbian OS, Palm OS, TinyOS, JavaOS, SCOSTA and MULTOS, is based on the attributes in each of the broad categories described in section 2.1.

A indicates that the corresponding attribute was specified for the Operating System

A indicates that the corresponding attribute was not specified /available for the Operating System

An X indicates that the corresponding attribute is not satisfied /supported by the Operating System

2.2.A AIMS /GOALS

CSE,UCE,OU 46 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

2.2.B DESIGN PRINCIPLES

Attributes Symbian Palm TinyOS JavaOS SCOSTA MULTOS OS OS

Interoperability

Reusability

Attributes Symbian Palm OS TinyOS JavaOS SCOSTA MULTOS OS

Robustness

Concurrency

Efficiency

Modularity

Standardization

Simplicity

Low Power overhead

Portability

Low System Overhead

Speed

Dynamic

Security

Quick Turnaround time

Easy

Small Memory Footprint

Multiple Platforms

Integrity

CSE,UCE,OUCompatibility 47 IDRBT

Simplify application development Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Flexibility

Concurrency

Low System /Power Overhead

Ubiquitous use of servers

Standardization

Ease the development

Limited Resources

Pervasive Asynchronous Services

Event-centric

Low Duty Cycle Operations

Extensibility

Support for availability

Portability

Non-Proprietary X

Security and Integrity

Modularity

Separation of user interfaces from services

Open Standards

Compatibility

2.2.C FEATURES

CSE,UCE,OU 48 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Attributes SYMBIAN PALM TINYOS JavaOS SCOSTA MULTOS OS OS

Object-Oriented (C++, Java)

Kernel X

Deletion of application over lifetime of a card

Certification Authority

Memory Management X

Interrupt Driven

Easy to use

Reusable Components

Efficient

Dynamic Remote Loading

Multimedia

Event-Driven Model

File Management X

Generic

Dynamic Application Management

Scheduling

Process Management X

Cross Platform Development

Networking

Good Performance (Fast)

CSE,UCE,OU 49 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Exceptional Handling X

Robust Business Model

Multitasking/Multithreadin g

Component Programming Model

Small Memory Footprint

GUI

Security

Desktop Synchronization

Multi-application Support

Maturity

Data Management

2.2.D ARCHITECTURE

Attributes Symbian Palm TinyOS JavaOS SCOSTA MULTOS OS OS

Layered Architecture

Support for Microkernel

Hardware Abstraction Layer

Device Drivers

Separate Network Layer

Presence of a Virtual Machine

User Interface

Integration with Hardware

CSE,UCE,OU 50 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

2.2.E SECURITY

Attributes Symbian Palm TinyOS JavaOS SCOSTA MULTOS OS OS

Signed Certificate

Limited Memory Safety

Security Environment

Data Confidentiality

Data Integrity

Biometrics

Data Caging

Greater Memory Safety / Security

Support for Cryptography

Secure Messaging

Security Architecture

Support for Security Model

2.2.F APPLICATIONS

Attributes Symbian Palm TinyOS JavaOS SCOSTA MULTOS OS OS

Mobile Phones

(Smart Phones)

Wireless Sensor Networks

CSE,UCE,OU 51 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Embedded Devices/ Systems

Network Access Control

Identity Cards

Embedded Robotics

e-passports

PDAs

Network Computers

ATMs

Electronic Devices

Payments

Sensor Actuator Networks

Military Applications

2.3 Summary We have made an attempt to compare the popular operating systems for small and portable devices like Symbian OS, Palm OS, TinyOS, JavaOS, SCOSTA and MULTOS for various attributes in each of the broad categories. The aim behind this chapter is to give a comparative study of various operating systems for small devices and to project their features and scenarios of use which can form the basis for developing various applications.

CSE,UCE,OU 52 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Chapter 3: Smart Card Operating System for Transport Application (SCOSTA)

3.1 Introduction SCOSTA (Smart Card Operating System for Transport Application) is a complete implementable Smart Card Operating Systems Standard. These standards are absolutely generic and are deployment- ready for all kind of Identity applications like Citizen ID card, PDS card, Election Card, BPL Card, and PAN Card etc. SCOSTA is primarily based on ISO-7816 standards and can comply with any international requirements. The SCOSTA describes the minimum support for the application using the Smart Cards. A SCOSTA compliant operating system will also be compliant to the ISO7816-4, -8 and -9 standards.

Smart cards are secured electronic devices that are used for keeping data and other information in a way that only "authorized" users are permitted to see or write the data.

SCOSTA is a smart card deployment for Indian driving licenses and vehicle registration certificates. The aim behind the project is to standardize and secure the data of the transport department (MoRTH), Government of India.

Porting of a smart card operating system to a processor involves writing functions that operating system calls to access various features of the processor. The final unified code, generic and processor specific, is tested on an emulator before developing its hard mask.

CSE,UCE,OU 53 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

A smart card operating system code is divided into two parts, the processor dependent functions and processor independent codes. Processor dependent codes include those codes where the operating system requires the Input/output functions. For example, EEPROM read/write communication with the reader (transmitting and receiving bytes from reader) and memory mapping of the code. Also, each processor has some special registers which set some values like baud rate. Porting of a smart card operating system to a processor involves coding of the functions that the operating system calls to access various features of the processor.

The code of SCOSTA has been written in C++, hence it has a number of source and include files which have been kept in separate source and include directories respectively. The source directory contains files and directories with the names of the processors. The files present are all processor independent while the files in the directories are all processor dependent files. A similar structure exists for files and directories in the include directory. The code of the operating system is formed by processor independent source and include files and by processor dependent source and include files of a processor.

The processor independent files include a main method, methods for sending ATR, receiving a PPS request, and sending the PPs, functions for 3DES encryption and decryption, functions for doing an external and internal authentication and various file handling functions. The functions written in the processor independent code call functions which require processor dependent code. Processor dependent files include functions to receive bytes from card reader, send bytes to card reader, generate random numbers, read from EEPROM and write to EEPROM, and functions to initialize various special registers for the processor to the appropriate settings.

Smart cards are secured electronic devices that are used for keeping data and other information in a way that only "authorized" users are permitted to see or write the data. SCOSTA specifications were defined primarily by National Informatics Centre (NIC),Government of India and IIT Kanpur. The SCOSTA specification is largely compliant with the international ISO 7816 standard (parts 4 to 9) for smart cards. The specifications drawn for the operating system, key management system, application and card layout and ISO definitions are mandatory to be complied with and form an integral part of SCOSTA and associated applications. In addition, the cards for use with these applications must comply with the ISO 7816 standard (parts 1 to 3) that detail the electrical, physical, and communication aspects for smart cards. The relevant standards for the contact-less mode of communication are ISO14443 (parts 1 to 4) that detail the electrical characteristics and contact-less protocol for contact-less mode of communication. SCOSTA can be implemented on any microprocessor based smart card. The applications specify the memory requirement for the card.

CSE,UCE,OU 54 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Directory Structure of SCOSTA

3.2 Objectives The SCOSTA project was initiated with the following principal objectives.

i. Standardization of Information The card layout, data fields and other relevant information stored on the card and the back-end have been standardized to ensure that information on all cards (issued wherever in India) is uniform and can be read and written all over India. ii. Inter-operability Since the Indian applications are to be deployed nationwide, it is essential for the standards to be interoperable and therefore, SCOSTA specifications deal fully with this aspect. All non- interoperable features are discouraged and are therefore non-compliant and do not form part of SCOSTA specifications iii. Multi Vendor Support / Non-Proprietary Keeping in view the need for future up-gradation, multi vendor support and the critical requirement of the specifications and product to be non-proprietary, it is essential to have the operating system specification to be open and standard. iv. Security and Integrity of Data A microprocessor based smart card can ensure that only authorized persons can read or write the application data stored in the card. SCOSTA supports both password based and key based authentication of users. Additionally, the SCOSTA-CL also supports the secure messaging and session keys for communication between the reader and the card. The application specifications include secure key management systems that ensure that only officials authorized to change the card data can do so and that it is not possible to create forged identity.

3.3 Smart Cards Smart Cards are used extensively for data security and authentication purposes in various ID card based applications. The data security in smart card is provided by access control based on passwords and cryptographic techniques. The smart card chip carries an operating system which implements cryptography and provides secure storage of data for application for interacting with the smart card. It is possible to integrate larger data storage and better security on a single chip which provides data security against unauthorized access and modification of data. Such kinds of chips when integrated in plastic are known as smart cards.

CSE,UCE,OU 55 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

The smart card was first introduced by German Scientist Helmut Grottrup and Jurgen Dethloff in 1968.By the 1990s,the smart cards were extensively used in France with the number rising to as much as 60 million cards in France alone. In 1994 smart cards came into the use of payment application by joint efforts of Master card and Visa together. Currently smart cards are used in many countries for various applications including passport applications, health care applications, institute identity cards, payment systems, Telecommunication Applications, Financial Transactions etc.

The Smart card is thus defined as a plastic card with integrated circuit embedded inside it with capability of transmitting, storing and processing of data. Smart cards are categorized into three groups – memory cards, microprocessor cards and contact-less cards.

Memory cards: The basic purpose of these cards is to protect unauthorized read and write access to the data and provide some basic security related operations using a simple security mechanism. The simple technologies and low cost of these cards are the major advantages of these cards in many applications. One of the disadvantages of these cards is that they can’t be reused and recharged. Once a card is empty, it must be discarded. These cards were used in telephone applications, transport and vending machine applications.

Microprocessor cards: These cards were first used in the bank cards in France. Apart from bank cards, these cards can be used in identification, secure data storage and electronic signatures applications. These types of cards have processor inside it for carrying out various security related operations and have large storage capacity compared to the memory cards.

Contact-less cards: In these cards, data and power is transferred without any electrical contact between the card and the reader. The typical distance between the card and the reader for communication is around 10 to 15 cms. The power required for the operation of the card is generated with the help of a radio frequency (RF) field. These cards are used in a wide variety of applications like passport, ticketing, identification cards of company etc.

3.4 Physical Layout and Components of a Smart Card Smart card is a plastic card with a chip module embedded inside it. This module has 8 contact pads on it. The contact pads are used for different purposes. I/O Contact Pad: This contact pad is used for communication of data from the card to the reader. Since, there is only one contact pad for data transfer, the communication with the card is half duplex. At a time the card can either receive data or send data to the terminal. Terminal is the device which exchanges information with the card. Vcc pad: This is used to supply external power to the card. GND pad: This is connected to the ground of the external terminal. RST pad: This is used by the terminal to send reset signal to the card. At any point of time, the card can be reset by the terminal using this pad. Vpp pad: This is used for supplying programming voltage to the card. The additional voltage may be needed for the programming of data onto the EEPROM. CLK pad: This is used to transmit the clock signal to the card.

CSE,UCE,OU 56 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Physical Layout and Components of a Smart Card A smart card has various components inside the chip. These include CPU, EEPROM, ROM, RAM, communication interface etc. The ROM contains the card’s operating system. This operating system uses the EEPROM for storing and retrieving data in the smart card organized as files. The RAM is the volatile working memory used by the programs running on the CPU. Most smart card chips today have 8-bit micro-controller with varied EEPROM sizes around the range of 4KB to 144KB,ROM sizes around the range of 4KB to 200KB and RAM sizes around the range of 256 bytes to 6KB.The configuration of various components of the card depends upon type of the card, cost of the card, application requirements etc.

3.5 Smart card Operating System The smart card processor executes a software that provides a standard interface. This software is known as operating system. The major functionality of the operating system is to provide standard way of information interchange between the card and the terminal device, or a computer, through smart card interface device commonly known as smart card reader. The communication between the smart card reader and the smart card is carried out in form of commands and their responses as follows. 1. The smart card reader sends a command to the card operating system. 2. The smart card operating system receives command via serial I/O interface. 3. The card operating system executes the command and sends out a response that includes the status code to indicate errors if any. Apart from the information exchange and the execution of commands, smart card operating system also provides security of data against unauthorized access and file management. Thus the card operating system receives commands from the reader, interprets the commands, executes them and sends the responses. The basic unit used for the command and the response transmission is known as Application Protocol Data Unit (APDU).

3.5.a APDU Structure

CSE,UCE,OU 57 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Commands and responses are transferred in the form of APDU structure. The APDU used for transfer of the command is known as command APDU, while the APDU used for sending the response is known as response APDU. The command APDU has two parts – command header and command body. The command header contains CLA, INS, P1 and P2 bytes. The command body has Lc byte, command data field and a Le field.

• CLA: This is the first byte in the command APDU. This byte encodes the class of the command, logical channel number etc. The class of the command as indicated by this byte can be a plain command or the command with secure messaging. • INS: This is the second byte of the command APDU and identifies the instruction to be executed. • Command Parameters (P1 and P2): These command parameter bytes are related to the INS byte and further qualify the instruction. • Lc byte and command data field: Lc byte provides the length of the command data field while command data field gives the data required for command execution. The presence of Lc byte and command data field depends upon the type of the command. If the command is an input command or a bi-directional command, the Lc byte and command data field are present. • Le field: The value of this field conveys the information about the maximum number of bytes the reader expects in the response field. This field may be empty for an input-only command. There are four types of commands. Type I: In this type of command, the command body and the response data are absent. A type I command APDU does not have Lc, command data field and Le field. Type II: In this type of command, Le field is present while the Lc byte and command data field are absent. Such a command is output-only command. Type III: In this type of command, Lc byte and command data field are present while Le field is absent. Such a command is an input-only command. Type IV: In this type of command, the Lc byte, command data field and the Le field are all present. Such a command is a bi-directional command.

The response of the command is sent using the response APDU and it has two parts, response field and status bytes. • Response field: The card gives out the response to the command in the response field. The number of bytes present in the response field cannot exceed Le field as given by the reader in the command APDU. • Status bytes: These bytes convey the status of the command processing after command execution.

3.5.b Communication Modes There are two modes of communication between the reader and the card-contact mode and contact-less mode. 3.5.b.A Contact Mode

CSE,UCE,OU 58 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

In the contact mode, communication takes place through electrical connections between the reader and the card. T=0 and T=1 are the protocols used for the contact communication.

T=0 is a byte oriented, half-duplex protocol i.e., at one time either the card or the reader can transmit signals. When a reader sends the command then the card is in the receive mode. When the card sends the response the reader is in the receive mode. Since this is a byte oriented protocol, command and response APDUs are transferred using communication handshake for each byte.

T=1 is half-duplex block-oriented communication protocol. Therefore, at a time only one party can be in the sending mode and the other will be in the reception mode. The command and response APDUs are transferred using blocks. Some kinds of additional blocks are used for acknowledging the previously sent blocks and to control information exchange between the reader and the card. These additionally supported blocks apart from the blocks for APDUs transfer provide reliability in the communication.

3.5.b.B Contact-less Mode In the contact-less mode, the card is not in physical contact with the reader and radio frequency field is used for communication. The card generates power using this RF field. The same RF field is also used for exchange of APDUs between cards and the reader.

3.5.c Communication Parameters Communication parameters are used by the OS for the communication with the reader. Some of these parameters are global in nature and affect the card operations in general. Other parameters are protocol specific ones. For example, parameters like programming voltage, programming current etc. are global parameters and are used by all protocols supported by the card. Parameters like data rate, block waiting time, character waiting time, frame size, etc. are specific to the T=1 protocol.

When the contact card is initialized by providing a power, the processor gets reset and provides an initial sequence of bytes indicating the card capabilities. This sequence is known as Answer To Reset or ATR. An ATR has information about protocols supported by the card and possible communication parameters for each of the protocol supported. The reader selects one of the protocols from the available protocols and negotiates the communication parameters for that protocol. This negotiation of communication parameters and selection of a protocol among the available protocol happens through handshake of bytes known as Protocol Parameter Selection (PPS) bytes. The PPS request can come immediately after the ATR is given out by the card. If the PPS request arrives after receiving the first command, the request is not processed. This means that it is not possible to change the protocol or its parameters in the middle of a session.

Communication parameters for the contact-less protocol are indicated by using the Answer To select (ATS). An ATS is a string that card returns to start the contact-less communication with the reader. The ATS has information about baud rate for transmission, maximum frame size that the card can receive etc. The data transmission rates can further be negotiated and selected by the PPS data exchange. The PPS request is enabled after ATS is given out by the card and is disabled after the card receives the first command. Since, the PPS request is disabled, communication parameters cannot be changed during the session.

3.5.d Communication of APDUs The APDUs are transmitted using Transmission Protocol Data Units (TPDU). TPDUs define the bytes transported by the transmission protocols. They can be regarded as protocol dependent containers

CSE,UCE,OU 59 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009 that transport data, to and from the card. The TPDUs used to carry to command are known as command TPDUs and TPDUs used to carry response are known response TPDUs.

In the case of T=0 protocol, an APDU needs to be converted to a T=0 protocol TPDU for the transmission. In this protocol, a TPDU can support data transfer only in one direction. Thus, a type IV command cannot be carried using a single TPDU. Since it involves data transfer in both directions. Therefore in this protocol, type IV command is broken into two commands one of type II and another of type III and carried in two separate TPDUs.

In the case of T=1 protocol, the command and response APDUs are encapsulated in blocks. The blocks in this protocol are transferred as TPDUs. In this protocol, it is possible to transmit all types of commands in a single TPDU.

In the case of contact-less protocol, the command and response APDUs are encapsulated in blocks. In this protocol, frames are used for data exchange. Therefore, blocks are transferred in frames.

3.5.e Basic Data Structure The data is stored in the form of files in the card. SCOSTA will support two categories of files - Dedicated Files (DF) and Elementary Files (EF). These files are arranged in a tree structured fashion with the root of the files known as Master File. The structure of the file system will be that of a tree with depth restrictions because of the limited size of EEPROM where files are stored may cause a CREATE FILE command to fail, if any, not less than 4 (including the MF and EF). Thus it will be possible to have at least one MF, one DF under the MF, another DF under this DF and EFs under the last DF. At each node of the tree, there can be several children nodes, either of type DF or of type EF.

The files under the MF will be global for all applications. The files pertaining to each application shall be stored under a DF node in the file system tree. An application may have sub-applications each represented by an individual DF under the parent DF. In such a case, the application may organize the files as global within the application and local for each sub-application.

3.5.f Logical File Organization EFs store the data related to the applications. DFs are placeholders for the EFs and DFs in the directory tree structure. These DFs are used for identifying application if the OS supports multiple applications. The files stored under an application specific DF are used only for that application.

3.5.f.i Elementary Files The EF files are used to keep the data pertaining to application. An EF can be of following types.

3.5.f.i.A Transparent EF: These files contain unstructured data as a stream of bytes. Application can organize the data in whichever form needed.

3.5.f.i.B Linear EF with fixed length record: These are record files containing records fixed in size. The records in these files are linearly stored.

3.5.f.i.C Linear EF with variable size record size: These are record files containing records varying in sizes. The records are linearly stored.

3.5.f.i.D Cyclic EF with fixed size of records: The fixed length records in these types of EFs are logically stored circularly. Thus when a record is added to the file, the oldest record is deleted if there is not enough space in the file.

CSE,UCE,OU 60 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

3.5.g File Referencing Methods Each file will have one 16-bit file identifier (with unique identifier for all EFs and DFs under a single DF). The EFs can also be referenced using another short EF identifier (5-bits) given at the time of CREATE FILE command. The short EF-identifiers need not be unique. No assumptions shall be made by the SCOSTA about the relation between the 16-bit file identifier and 5-bit short file identifier for the EFs. While selecting a file using short EF identifier, the results will be unpredictable if two or more files exist with the same short EF identifier. Each DF in the file system will also have the DF name that shall be unique among all DFs in the file system. Thus it will be possible to refer to any DF with its name irrespective to its location in the file system. It will be mandatory for each file to have the 16-bit file id. In addition, all the DFs will have a unique name (1 to 16 bytes long). Following are the methods to refer to files stored in the card:

3.5.g.i Referencing by file identifier: The EFs and DFs can be selected by using two byte file identifiers. This method of referencing with a file identifier is applicable to the currently selected DF. Therefore, to select a file uniquely, the EFs and DFs under currently selected DF should have unique file identifiers.

3.5.g.ii Referencing by path: A file (EF or DF) can be selected by using path. The path starts with file identifier of the MF, or file identifier of the currently selected DF, and ends with the file identifier of the file to be selected. In between these two identifiers, the path consists of zero or more file ids of intervening DFs.

3.5.g.iii Referencing by short identifier: EFs have an optional short file identifiers (SFIDs) associated with them. An EF under the currently selected DF may be selected implicitly using its SFID in various commands. However, SFIDs cannot be used in the path and are not the substitute for the regular file identifier.

3.5.g.iv Referencing by DF name: DFs can have optional names associated with them. It is possible to select DF by its name. In order to select DF by name, the DF names should be unique across all DFs in the file system.

3.5.h Data Referencing Methods

CSE,UCE,OU 61 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Data stored in the card can be referenced as records, data units or data objects. In SCOSTA compliant OS, certain data objects may be made available. These will be in compliance to the ISO/IEC 7816-6. For example, some of the relevant DOs may be used to represent the Card’s Sequence Number, Primary Account Number, and Cardholder’s Name etc. The data objects shall be accessed using GET DATA and PUT DATA commands. DOs will be attached to a DF. GET DATA/PUT DATA commands will operate on the DOs attached to the selected DF.

All SCOSTA compliant cards will have a DO with tag 46 (hex) for pre-issuing data. This DO will be available in the life time of the card and will be used to return the chip serial number of the chip embedded in the card and as provided by the chip manufacturer. If the embedded chip does not support the way of providing a unique chip serial number, 32-bit binary value containing all 0s will be returned. Otherwise the unique chip serial number will be returned by GET DATA command. PUT DATA command for DO 46 will not modify the value. The DO 46 will be available at least in the MF and will have variable length. The applications can use the GET DATA command with Le=0 to find the length of the chip serial number. In response to GET DATA command with Le=0 the exact length will be returned to the application in the status bytes (SW1=6C, SW2=exact length).

The data is stored as a sequence of records in the record files or as a sequence of bytes (data- units) in transparent files. In case of transparent EFs, data can be accessed by giving offset of the first byte from the beginning and the number of bytes to be read. While in case of record oriented files, records can be accessed using record identifier or record number.

3.5.h.i Record referencing by record identifier: The record identifier is provided by the application at the time of creating a record. Within an EF, record identifier can be same for two different records.

3.5.h.ii Record referencing by record number: The record numbers are unique and sequential within an EF. The numbers are assigned to record while writing in case of files with linear structure. While the record numbers are sequentially assigned in the opposite order in case of cyclic files i.e., the record with record number 1 is most recently created record.

Along with data storage in the form of records, ISO standards provide variety of ways to organize data in tagged format. Data is organized as 3-tuple with members tag, length and value (TLV) known as data objects and it is encoded in simple TLV or using Basic Encoding Rules (BER). In simple TLV form, tag is 1 byte, length is 1 byte and no nesting of DOs is done while BER is coded using ASN.1 representation.

There are two types of data objects (DOs) – primitive and constructed. In constructed DOs several primitive or constructed DOs can be nested in a constructed DO while in case of primitive DOs no nesting is done.The DOs can be stored under MF or DF in the smart card. The EF in the smart card can contain primitive as well as constructed DOs for storage of FCP of a file, encoding of file identifier, etc.

3.5.h.iii Data Unit referencing: The data unit referencing shall be available for the transparent EF. The operating systems may implement data unit referencing mechanism for the record structure files as well primarily intended to debug the applications. However in such a case, the data returned may include the structural information (meta-data) as well. SCOSTA compliant applications will make no assumptions about the structure of the meta-data.

The cards shall support variable data unit size (among these support for 8-bits wide data units is mandatory for all SCOSTA compliant cards).

3.5.i File control information

CSE,UCE,OU 62 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

SCOSTA compliant OS will support the FCP templates at least to be returned to the application during the SELECT FILE command execution. In case SELECT FILE command demands other templates, meaningful default information should be supplied if the other templates are not supported.

3.5.i.i File Control Parameters (FCP) Control information of a file stored inside the card is associated with the file at the time of file creation and is known as a collection of file control parameters (FCP). These file control parameters include file identifier, short file identifier, DF name, file descriptor byte (FDB) that specifies the type of the file, number of records, size of records etc.

3.5.j Security architecture SCOSTA compliant OS will support at least the following security architecture

3.5.j.i Security status The SCOSTA compliant OS will support the following three security statuses. • Global security status (related to the MF authentication processes) • File-specific security status (related to the DF authentication processes) • Command specific security status (related to the command authentication processes)

3.5.j.ii Security attributes It will be possible to attach security attributes to the files using the FCP. Both compact form as well as the expanded form of defining security attributes must be supported. The SCOSTA compliant OS shall support the referencing of security attributes for the files (using the FCI mechanism). Other methods of referencing the security attributes are optional for SCOSTA compliant operating system.

Similarly SCOSTA compliant OS shall support the access mode bytes (AM bytes). Other AM bytes are optional for SCOSTA compliant OS. No proprietary coding shall be used in AM/SC bytes.

3.5.j.iii Security Environments A security environment (SE) is a logical container having security components required either for the security mechanism of the card or for secure messaging. The SE is identified using security environment identifier and it contains control reference templates (CRTs). The CRT is set of control reference data objects (CRDOs) which have the information about parameters such as key, the algorithm, the initial value (IV) etc. in the form of DOs. These CRTs are used for operations such as authentication, encryption, and checksum computation etc. Following are the types of CRTs and operations associated with them.

Confidentiality template (CT): This template has CRDOs for the confidentiality related operations such as encryption, decryption etc.

Crypto-check-sum template (CCT): This template has CRDOs for the computation and verification of check-sum.

Authentication template (AT): This template has CRDOs for internal authentication, external authentication and mutual authentication operations.

Hash template (HT): This template has CRDOs for hash computation.

Digital signature template (DST): This template has CRDOs for digital signature calculation.

CSE,UCE,OU 63 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

The operations for which a CRT is defined is controlled by a CRT usage qualifier. The CRT usage qualifier specifies the operation for which the parameters specified in a particular CRT are to be used. Each of the CRT may or may not have CRT usage qualifier associated with them. If the CRT usage qualifier is not available then the default value is taken as specified in SCOSTA-CL document.

The card always has a default SE which contains templates for performing various security related operations such as encryption, decryption, check-sum computation and verification. This default SE is known as current SE and it can be empty (containing no templates). Parameter for security operations are taken from the current SE unless some other SE is explicitly specified.

The security environments (SEs) shall be stored either in an EF or in the FCP of the DF with a tag 7B. In case the SEs are stored in an EF, the id of the EF shall be notified with tag 8D in the FCP of the corresponding DF. The default SE for an application will be all empty.

3.5.j.iv Security mechanisms The SCOSTA compliant OS shall support at least the following security mechanisms:

•Entity authentication with password (VERIFY command): In the password based authentication, the password entered by the user is verified against the stored password in the card.

•Entity authentication with key (EXTERNAL AUTHENTICATE, INTERNAL AUTHENTICATE and MUTUAL AUTHENTICATE commands): Key based authentication is based upon challenge and response mechanism. The challenge is given to the party to be authenticated, which operates on the challenge using symmetric key and provides a response to the challenge issuing party. The challenge issuing party verifies the response against previously issued challenge for successful authentication. For example, a response may be formed by encrypting the challenge. Key based authentication includes internal authentication, external authentication and mutual authentication. In the internal authentication, the card is authenticated with the reader to ensure genuineness of the card while in external authentication, the reader along with the application is authenticated to the card. In mutual authentication, internal as well as external authentication takes place simultaneously, i.e., card and reader authenticate each other.

•Data authentication (computation/verification of cryptographic checksum). Triple DES (3DES) algorithm in CBC mode will be used for Data authentication, data encipherment and decipherment. This includes computation and verification of cryptographic checksum on the data. The checksum is computed in order to provide integrity of data so that any modification in the data can be detected. The procedure of checksum computation and verification requires a key.

• Data encipherment

• Data decipherment

Triple DES (3DES) algorithm in CBC mode will be the default algorithm (i.e. if the algorithm reference is not given or given as default in the appropriate commands/DOs) used for Data authentication, data encipherment and decipherment.

The entity authentication mechanisms described above are used for checking the security condition. The access to the files and DOs is granted, if the security conditions are met. In addition to above authentication mechanism, the card supports other security mechanisms including data confidentiality, integrity and command confidentiality and integrity using secure messaging.

CSE,UCE,OU 64 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Data confidentiality: This mechanism provides confidentiality by data encryption and decryption so that only the genuine key holders are able to see data.

Data integrity : This mechanism deals with the computation of message authentication code (MAC) or hash. For different messages it is almost impossible to generate same MAC hence it is used to detect alteration in messages.

Secure messaging: This mechanism is used for secure transmission of commands and responses. This secure transmission is achieved by confidentiality and integrity over command and response.

3.5.j.v Access rule references The access rule (in expanded or in compact format) for a file can be stored in the file’s FCP. These rules shall specify under what security conditions certain operations on that file are permitted. The access rules for the DOs can be stored in the FCI of the corresponding DF.

3.6 SCOSTA supported commands SCOSTA compliant cards have two kinds of storage – volatile and non-volatile. All instructions that update the non-volatile information will execute atomically in the SCOSTA compliant cards. The effect of all such commands will be either due to the complete execution or due to no execution. The cards may use the subsequent power up to finish the last command. The commands supported by the SCOSTA are categorized in the following categories. All of these commands are appropriately referred to the ISO/IEC documents.

• File related commands • Security related commands • Other commands

3.6.a File related commands in SCOSTA SCOSTA compliant OS will support the following commands as mandatory commands.

3.6.b Security related commands in SCOSTA The following commands will be supported by the SCOSTA compliant operating systems.

CSE,UCE,OU 65 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

3.6.c Other Commands The following commands will also be supported in the SCOSTA. • GET DATA command • PUT DATA command • GET RESPONSE command

3.7 Summary SCOSTA (Smart Card Operating System for Transport Application) is thus an interoperable and an implementable Smart Card Operating Standard, which brings about uniformity for a wide variety of applications.

Chapter 4: Mobile Payments Architecture

CSE,UCE,OU 66 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

4.1 Existing Model

4.1.1 Entities The entities involved in the payment procedure are the Telecom Service Providers (TSP), the Mobile Payment Provider (MPP), bank, customer and the beneficiary. The participation of the entities in a mobile payment process is highlighted in the figure.

4.1.1.a Bank: Financial institutions approved to take deposits and debit and credit the accounts of the customer. Banks are regulated by RBI.

4.1.1.b Telecom Service Provider (TSP) : Licensed telcos which provide mobile and other telecom services. Telcos are regulated by TRAI.

4.1.1.c Mobile Payment Provider (MPP) : Is a entity which facilitates financial transactions within mobile phone consumers. It is important to note that MPP is a logical entity. A bank can choose to be its own MPP or it can choose a third part entity as its MPP.

4.1.1.d Customer : The buyer or the payer who purchases goods/services from another entity.

4.1.1.e Beneficiary : The seller or the payee who benefits from the purchase of a good/service.

4.1.1.f Payment Settlement Agency: (In the future) An RBI authorized agency for real-time settlement on a per-transaction basis. (Initially, in the absence of such an agency, banks will transfer funds using existing RTGS/NEFT mechanisms).

4.1.2 Assumptions 1. The Banks perform transfer of money between accounts using existing channels such as INFINET. They do not go through any MPP to transfer money. 2. Bank will have a registered mobile phone number linked to a customer's account if he wishes to have m-commerce enabled. 3. Each account holder must register one default account to be used for mobile payments. 4. A MPP will have each of its customer's phone number and his account details. 5. TSP will have the subscriber's name and other details registered with his/her mobile number 6. Each MPP will be registered with an RBI authority and will be assigned an MPP ID (say 5 digits). Thus the concatenation of can be used to route

4.1.3 Payment Process There are three mobile payment processes: 4.1.3.a Pre-registered 3rd party : Payer selects beneficiaries from the list, similar to Internet Banking. There is no issue with this approach as the MPP information is entered and validated in advance (at the time of registration of the third party).

CSE,UCE,OU 67 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

4.1.3.b Payment to arbitrary 3rd party via phone number only: the customer and beneficiary may not be known to each other before this transaction. Eg: payment to an auto-driver, to a restaurant or small shop. There are two cases, pull and push described below.

A. Pull method: When the payment process is initiated by the beneficiary. This is similar to the usual payment process where the beneficiary provides the customer with an invoice and the customer then makes a payment.

B. Push method: In this case the customer initiates payment which is accepted by the beneficiary.

As the pre-registered 3rd party case is similar to currently-used Internet banking, it poses no new issues and is not considered further in this document. For arbitrary 3rd party, the payment model can be either pull or push but the architecture of the payment process will not change with it. It is only the protocols and the implementation level details that will change with the type of the payment process.

The Customer has to make a payment to a Beneficiary (given the Beneficiary's mobile phone number). Assumption is that the customer and beneficiary agree on the amount of payment and both the beneficiary and the customer are ready to exchange their phone numbers to complete the transaction. To reduce the chance of accidental or malicious errors, assumption is that each party knows the name of the other and they are using the mobile phones registered in these names.

The diagram depicts the communication links between the different entities involved in the mobile payment process.

4.1.4 Process Flow

CSE,UCE,OU 68 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Two designs have been proposed. In the first, the Banks/MPP have the information of the default account number. For any transaction, the Banks/MPPs locate among themselves the default account of each party. In the second design, the default account information is registered with the TSP.

4.1.4.a Bank-Centric Design Initially, the banks will use a broadcast protocol among themselves to locate the default account for a given mobile number. As the volume of transactions grows, this may be replaced by a control database run by RBI or its authorized agency such as IDRBT.

4.1.4.a.A Pull Method

1. Beneficiary opens the MPP application on his hand held and sends a message containing the phone number of the customer and the amount due. 2. The message is processed by the Beneficiary's Bank/MPP and a broadcast message is sent to all other Banks/MPPs to find the default account number corresponding to the given Customer's mobile phone number. 3. Customer's Bank/MPP which possesses its default account number replies with the account number. 4. Beneficiary's Bank/MPP sends the Customer's Bank/MPP a request for payment 5. Customer's Bank/MPP informs the Customer and asks for confirmation. 6. Customer confirms 7. Customer's Bank/MPP transfers the funds to Beneficiary's account.

CSE,UCE,OU 69 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

8. Beneficiary is notified.

The pull method requires the Customer to respond once and the Beneficiary's intervention only twice.

4.1.4.a.B Push Method

1. The Customer initiates payment by starting the MPP application and sending a message through it. The message contains the Beneficiary's phone number and the amount due and is processed by Customer's Bank/MPP. 2. Customer's Bank/MPP broadcasts Beneficiary's phone number 3. Beneficiary's Bank/MPP replies with the Customer's default account number and Beneficiary's name 4. Name of the Beneficiary is sent to the Customer 5. Customer checks the name and confirms 6. The payment is initiated 7. Beneficiary is informed about it 8. Beneficiary accepts 9. Customer's Bank transfers amount to Beneficiary's Bank 10. Beneficiary is informed about the transaction completion at the end

The push method of payment requires customer intervention and the Beneficiary is required to respond only once. If the end user uses this method to receive payment then it can be a slight inconvenience.

4.1.4.b TSP-Assisted Design

CSE,UCE,OU 70 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

The initiator of a transaction first sends a request to its TSP to obtain the default account and name of the 2nd party's TSP for this information. It may use the mobile number prefix or the TRAI Mobile Number Portability database to determine the 2nd party's TSP.

4.1.4.b.A Pull Method

1. Beneficiary opens the MPP application on his hand held and sends a message containing the phone number of the customer and the amount due. 2. The Beneficiary’s Bank/MPP sends the Customer's phone number to its TSP to obtain the default account number and name of the customer. 3. Customer's default account number and name is returned to the Beneficiary's Bank/MPP 4. Beneficiary's Bank/MPP sends payment request to Customer's Bank/MPP 5. Customer's Bank/MPP informs the Customer about the amount due and name of the Beneficiary. 6. Customer sends acceptance to its Bank/MPP 7. Customer's Bank/MPP transfers amount to Beneficiary's Bank/MPP 8. Beneficiary is notified

4.1.4.b.B Push Method

CSE,UCE,OU 71 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1. The Customer initiates payment by starting the MPP application and sending a message through it. The message contains the Beneficiary's phone number and the amount due and is processed by Customer's Bank/MPP. 2. Customer's Bank/MPP finds out Beneficiary's default account number by querying its TSP 3. Beneficiary's TSP returns the default account number and name corresponding to the phone number. 4. Customer receives the name of the corresponding to the phone number he had earlier typed. This is to rule out any errors that might occur due to typing. 5. Customer checks the name and confirms 6. The payment is initiated 7. Beneficiary is informed about it 8. Beneficiary accepts 9. Customer's Bank transfers amount to Beneficiary's Bank 10. Beneficiary is informed about the transaction completion at the end

4.1.5 Sequence Diagrams 4.1.5.a SAME BANK-PUSH METHOD

CSE,UCE,OU 72 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Abbreviations: CM---Customer’s Mobile. CMPP---Customer’s Mobile Payment Provider. BMPP---Beneficiary’s Mobile Payment Provider.

CSE,UCE,OU 73 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

BM---Beneficiary’s Mobile.

Description:

1. The Customer initiates the mobile payment application in his/her mobile and enters the PIN. 2. The Customer’s mobile payment provider authenticates it and intimates the Customer accordingly. 3. If the Customer is an authorized user then the Customer enters the Beneficiary’s mobile number and the amount. 4. Customer’s mobile payment provider will broadcast the Beneficiary’s mobile number to all the Beneficiary mobile payment providers. 5. The corresponding Beneficiary with the mobile number given by the Customer‘s mobile payment provider will respond to Customer’s mobile Payment provider with the Beneficiary’s name. 6. Customer’s mobile payment provider will forward Beneficiary’s name to Customer in order to confirm whether the Customer is willing to pay for that Beneficiary or not. 7. Now the Customer will accept with the Beneficiary name given by its mobile payment provider. 8. Customer’s mobile payment provider will send the payment request to the Beneficiary’s mobile payment provider. 9. Beneficiary’s mobile payment provider will send the payment request to the Beneficiary. 10. Beneficiary will accept for the payment. 11. Beneficiary’s mobile payment provider will now send the confirmation to Customer’s mobile payment provider. 12. Now the Customer’s mobile payment provider will inform the Bank to debit the amount to Beneficiary’s account.[Customer’s Bank will check with the Beneficiary’s name whether he/she has an account in its Bank. Here the assumption is the Customer and the Beneficiary are from same bank the payment is done within the bank.] 13. Bank will inform the Customer’s mobile payment provider that the payment has been done. 14. Bank will inform the Beneficiary’s mobile payment provider that the payment has been received. 15. Customer’s mobile payment provider will inform the Customer that the payment has been done. 16. Beneficiary’s mobile payment provider will inform the Beneficiary that the payment has been received.

4.1.5.b DIFFERENT BANK -PUSH METHOD

Abbreviations: CM---Customer’s Mobile. CMPP---Customer’s Mobile Payment Provider. CBank---Customer’s Bank. BBank---Beneficiary’s Bank. BMPP---Beneficiary’s Mobile Payment Provider. BM---Beneficiary’s Mobile. PSA---Payment Settlement Agency.

CSE,UCE,OU 74 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Description: 1. The Customer initiates the mobile payment application in his/her mobile and enters the PIN. 2. The Customer’s mobile payment provider authenticates it and intimates the Customer accordingly. 3. If the Customer is an authorized user then the Customer enters the Beneficiary’s mobile number and the amount.

CSE,UCE,OU 75 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

4. Customer’s mobile payment provider will broadcast the Beneficiary’s mobile number to all the Beneficiary mobile payment providers. 5. The corresponding Beneficiary with the mobile number given by the Customer‘s mobile payment provider will respond to Customer’s mobile Payment provider with the Beneficiary’s name. 6. Customer’s mobile payment provider will forward Beneficiary’s name to Customer in order to confirm whether the Customer is willing to pay for that Beneficiary or not. 7. Now the Customer will accept with the Beneficiary name given by its mobile payment provider. 8. Customer’s mobile payment provider will send the payment request to the Beneficiary’s mobile payment provider. 9. Beneficiary’s mobile payment provider will send the payment request to the Beneficiary. 10. Beneficiary will accept for the payment. 11. Beneficiary’s mobile payment provider will now send the confirmation to Customer’s mobile payment provider. 12. Now the Customer’s mobile payment provider will inform the Customer’s Bank to debit the amount to Beneficiary’s account. 13. Customer’s Bank will check with the Beneficiary’s name whether he/she has an account in its Bank. If the Beneficiary doesn’t have an account it will forward the payment request to Payment Settlement Agency which will debit the Customer’s account and debits the Beneficiary’s account. Here the assumption is the Customer and the beneficiary are from different banks the payment is done by the Payment Settlement Agency]. 14. Customer’s Bank will inform the Customer’s mobile payment provider that the payment has been done. 15. Beneficiary’s Bank will inform the Beneficiary’s mobile payment provider that the payment has been received. 16. Customer’s mobile payment provider will inform the Customer that the payment has been done. 17. Beneficiary’s mobile payment provider will inform the Beneficiary that the payment has been received.

4.1.6 Summary

From the study of push and pull methods of payments it can be summarized that the push process of payment involves an exchange of more number of messages as compared to the pull process. This is because the push method of payment is error prone, to avoid that error an exchange of a few extra messages is necessary.

CSE,UCE,OU 76 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

4.2 PROPOSED MODEL

4.2.a Entities: 4.2.a.i Bank: Financial institutions approve to take deposits and debit and credit the accounts of its customers. Banks are regulated by Reserve Bank of India [RBI].

4.2.a.ii Telecom Service Provider (TSP): Licensed telcos which provide mobile and other telecom services. Telcos are regulated by Telecom Regulatory Authority of INDIA (TRAI).

4.2.a.iii Customer : The buyer or the payer who purchases goods/services from another entity.

4.2.a.iv Beneficiary : The seller or the payee who benefits from the purchase of a good/service.

4.2.a.v Payment Settlement Agency: (In the future) An RBI authorised agency for real-time settlement on a per-transaction basis. (Initially, in the absence of such an agency, banks will transfer funds using existing RTGS/NEFT mechanisms).

4.2.a.vi Switch: Every Bank has a corresponding Switch that maintains a database of the mappings of all its customer’s mobile number with the corresponding primary account number in that Bank. It also acts as a mediator between Bank and the TSPs.

4.2.a.vii Centralized Switch: It is the Centralized party that connects the Switches of all the Banks.

4.2.b Assumptions: 1. The Banks perform transfer of money between accounts using existing channels such as INFINET. 2. Each account holder must register one default account to be used for mobile payments. 3. TSP will have the subscriber's mobile number and the corresponding Bank’s name in which the subscriber has a primary account registered for mobile payments. 4. Every Switch of a Bank will have a registered mobile phone number linked to a customer's account if he wishes to have m-commerce enabled. 5. Bank will have each of its customer's phone number and his account details. 6. The mobile payments application is provided by M-payment Application Provider (MAP). TSP takes the help of MAP to load the application on to its subscriber’s Subscriber Identity Module (SIM) and TSP issues the corresponding PIN for the application to its subscriber. 7. TSP will act as a mediator between its Subscriber and the Switch of the Bank in which the subscriber has the primary account registered with mobile payments.

4.2.c Four Scenarios: 1. SAME BANK SAME TELCO (TSP): Customer and Beneficiary have Same TSPs and have primary accounts registered for mobile payments in the Same Bank. 2. SAME BANK DIFFERENT TELCOS (TSP): Customer and Beneficiary have Different TSPs and have primary accounts registered for mobile payments in the Same Bank. 3. DIFFERENT BANKS SAME TELCO (TSP): Customer and Beneficiary have Same TSPs and have primary accounts registered for mobile payments in Different Banks.

CSE,UCE,OU 77 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

4. DIFFERENT BANKS DIFFERENT TELCOS (TSP): Customer and Beneficiary have Different TSPs and have primary accounts registered for mobile payments in the Different Bank.

4.2.c.1 SAME BANK SAME TELCO --- PUSH MODEL

Abbreviations: TSP-----Telecom Service Provider.

Description: 1. The Customer initiates the mobile payment application in his/her mobile and enters the PIN. 2. The Telecom Service Provider authenticates it and intimates the Customer accordingly. 3. If the Customer is an authorized user then the Customer enters the Beneficiary’s mobile number and the amount.

CSE,UCE,OU 78 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

4. Telecom Service Provider will forward the Customer’s mobile number, Beneficiary’s mobile number and amount to the Switch of the Bank. 5. Switch will check if the Benficiary has a primary account number with its Bank. If the Beneficiary has an account in the Bank as that of the Customer then the Switch will inform the Telecom Service Provider and waits for the Beneficiary’s decision. 6. Telecom Service Provider will ask the Beneficiary about its decision. 7. Beneficiary will inform its decision to the Telecom Service Provider that it is ready for the payment. 8. Telecom Service Provider will inform Switch that Beneficiary is ready to accept the payment. 9. Switch of the Bank will inform its Bank to transfer the funds. 10. After the payment is done Bank will inform the Switch that the amount has been transferred to Beneficiary’s account. 11. Switch will inform the Telecom Service Provider that Payment has been done. 12. Telecom service provider will inform the Customer that the payment has been made. 13. Telecom service provider will inform the Beneficiary that the payment has been received.

4.2.c.2. SAME BANK DIFERENT TELCO S--- PUSH MODEL

CSE,UCE,OU 79 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Abbreviations:

CTSP---Customer Telecom Service Provider. BTSP---Beneficiary Telecom Service Provider.

Description:

1. The Customer initiates the mobile payment application in his/her mobile and enters the PIN. 2. The Customer’s Telecom Service Provider authenticates it and intimates the Customer accordingly. 3. If the Customer is an authorized user then the Customer enters the Beneficiary’s mobile number and the amount. 4. Customer’s Telecom Service Provider will forward the Customer’s mobile number, Beneficiary’s mobile number and amount to the Switch of the Bank. [Switch will check if the Benficiary has a primary account number with its Bank.] 5. If the Beneficiary has an account in the Bank as that of the Customer then the switch will inform the Telecom Service Provider and waits for the Beneficiary’s decision. 6. Beneficiary’s Telecom Service Provider will ask the Beneficiary whether he/she is ready for the payment and waits for the decision. 7. Beneficiary will inform its decision to its Telecom Service Provider that he/she is ready for the payment. 8. Beneficiary’s Telecom Service Provider will inform Switch that Beneficiary is ready to accept the payment. 9. Switch of the Bank will inform its Bank to transfer the funds. 10. After the payment is done Bank will inform the Switch that the amount has been debited from Customer’s account and credited to Beneficiary’s account. 11. Switch will inform the Customer’s Telecom Service Provider that Payment has been done. 12. Switch will inform the Beneficiary’s Telecom Service Provider that Payment has been done. 13. Customer’s Telecom service provider will inform the Customer that the payment has been made. 14. Beneficiary’s Telecom service provider will inform the Beneficiary that the payment has been received.

4.2.c.3. DIFFERENT BANK S SAME TELCO --- PUSH MODEL

Abbreviations:

CM---Customer’s mobile. TSP---Telecom Service Provider. S1---Switch1 corresponding to Bank1. B1---Bank1 (Customer’s Bank). B2---Bank2 (Beneficiary’s Bank). S2---Switch2 corresponding to Bank2. CS---Centralized Switch. BM---Beneficiary’s mobile. PSA---Payment Settlement Agency.

CSE,UCE,OU 80 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

CSE,UCE,OU 81 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Description:

1. The Customer initiates the mobile payment application in his/her mobile and enters the PIN. 2. The Telecom Service Provider authenticates it and intimates the customer accordingly. 3. If the Customer is an authorized user then the Customer enters the Beneficiary’s mobile number and the amount. 4. Telecom Service Provider will forward the Customer’s mobile number, Beneficiary’s mobile number and amount to the Switch of the Customer’s Bank. 5. Now the Customer’s Switch will check whether the Beneficiary have an account in its Bank. If it doesn’t find, Customer’s Switch will forward it to the Centralized Switch. 6. The Centralized Switch will find the corresponding Beneficiary’s Bank Switch and forwards it to that Switch. 7. The Beneficiary’s Bank Switch will now inform the Beneficiary’s name to the Telecom Service Provider. 8. Telecom Service Provider will now ask the Beneficiary whether he/she is ready for the payment or not and it waits for the Beneficiary’s decision. 9. The Beneficiary will inform the Telecom Service provider that he/she is ready for the payment.

10. The Telecom Service Provider will inform Beneficiary’s Bank Switch that the Beneficiary has accepted for receiving the payment. 11. The Telecom Service Provider will inform Customer’s Switch that the Beneficiary has accepted for receiving the payment. 12. Customer’s Bank Switch will inform the Customer’s Bank to transfer the funds. 13. Beneficiary’s Bank Switch will inform the Beneficiary’s Bank about the payment. Here payment will be settled by the Payment Settlement Agency. 14. After the Payment is done Customer’s Bank will inform its Switch that the amount has been debited from Customer’s account. 15. After the Payment is done Beneficiary’s Bank will inform its Switch that theamount has been credited to Beneficiary’s account. 16. Customer’s Switch will inform the Telecom Service Provider about the Payment completion. 17. Telecom Service provider will inform the Customer that the payment has been made. 18. Beneficiary’s Switch will inform the Telecom Service Provider about the Payment completion. 19. Telecom Service provider will inform the Beneficiary that the payment has been made.

4.2.c.4. DIFFERENT BANK S DIFFERENT TELCO S--- PUSH M ODEL

Abbreviations: 4. DIFFERENT BANK DIFFERENT TELCO --- PUSH MODEL CM---Customer’s mobile. TSP1---Customer’s Telecom Service Provider. S1---Switch1 corresponding to Bank1. B1---Bank1 (Customer’s Bank). CS---Centralized Switch. B2---Bank2 (Beneficiary’s Bank). S2---Switch2 corresponding to Bank2. TSP2---Beneficiary’s Telecom Service Provider. BM---Beneficiary’s mobile. PSA---Payment Settlement Agency.

CSE,UCE,OU 82 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Description:

1. The Customer initiates the mobile payment application in his/her mobile and enters the PIN. 2. The Customer’s Telecom Service Provider authenticates it and intimates the Customer accordingly.

CSE,UCE,OU 83 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

3. If the Customer is an authorized user then the Customer enters the Beneficiary’s mobile number and the amount. 4. Telecom Service Provider will forward the Customer’s mobile number, Beneficiary’s mobile number and amount to the Switch of the Customer’s Bank. 5. Now the Customer’s Switch will check whether the Beneficiary have an account in its Bank. If it doesn’t find, Customer’s Switch will forward it to the Centralized Switch. 6. The Centralized Switch will find the corresponding Beneficiary’s Bank Switch and forwards it to that Switch. 7. The Beneficiary’s Bank Switch will now inform the Beneficiary’s name to the Beneficiary’s Telecom Service Provider. 8. Beneficiary’s Telecom Service Provider will now ask the Beneficiary whether he/she is ready for the payment or not and it waits for the Beneficiary’s decision. 9. The Beneficiary will inform his/her Telecom Service provider that he/she is ready for the payment. 10. The Beneficiary’s Telecom Service Provider will inform Beneficiary’s Bank Switch that the Beneficiary has accepted for receiving the payment. 11. The Beneficiary’s Bank Switch will inform the Centralized Switch that the Beneficiary has accepted for the payment. 12. The Centralized Switch will forward the same message to Customer’s bank Switch. 13. Customer’s Bank Switch will inform the Customer’s Bank to transfer the funds. 14. Beneficiary’s Bank Switch will inform the Beneficiary’s Bank about the payment. Here payment will be settled by the Payment Settlement Agency. 15. After the Payment is done Customer’s Bank will inform Centralized Switch that the amount has been debited from Customer’s account. 16. After the Payment is done Beneficiary’s Bank will inform Centralized Switch that the amount has been credited to Beneficiary’s account. 17. Centralized Switch will inform the Beneficairy’s Bank Switch about the Payment completion. 18. Centralized Switch will inform the Customer’s Bank Switch about the Payment completion. 19. Customer’s Bank Switch will inform the Customer’s Telecom Service Provider about the Payment completion. 20. Beneficiary’s Bank Switch will inform the Beneficiary’s Telecom Service Provider about the Payment completion. 21. Customer’s Telecom Service provider will inform the Customer that the payment has been made. 22. Beneficiary’s Telecom Service provider will inform the Beneficiary that the payment has been received.

4.2.d Exceptional Handling:

1. If the Customer enters a wrong PIN then its TSP intimates the Customer that he/she is not authorized to use the application. 2. When the Customer’s TSP forwards the Customer’s mobile number, Beneficiary’s mobile number and the amount to the Switch of the Bank whose name was registered with the TSP, the Switch now checks if the Customer has a primary account registered with the Bank. If the Customer has an account registered, the transaction flows as shown in the above figures. If the Customer doesn’t have an account registered with the Bank, the Switch of that Bank informs the Customer’s TSP about the same and the TSP forwards it to the Customer.

CSE,UCE,OU 84 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

3. The Switch after confirming that the customer has a primary account registered with its Bank, informs its Bank to check if the Customer has sufficient balance to make the payment. If the Customer has sufficient balance the transaction flows are shown in the above figures. If the Customer doesn’t have sufficient balance to make the payment, the Bank will now inform its Switch which then forwards it to the TSP. The TSP will inform its Customer about the same. 4. The Switch after confirming that the customer has a primary account registered with its Bank and has sufficient balance, checks if the beneficiary also has an account in the same Bank. If so, the transaction flows as shown in the above figures. Otherwise, the Switch informs the Central Switch to forward the request to the Switch of the Bank in which the beneficiary has a Primary account registered for mobile payments. This case arises for models 3 and 4. 5. If none of the above error cases arise, the TSP asks for the Beneficiary’s consent. If the Beneficiary accepts the transaction flows are shown in the above figures. If the Beneficiary rejects the payment then the following have to be considered: a) In case of model 1, the TSP (Customer and Beneficiary have the same TSP) informs both the Customer and the Beneficiary that the transaction has been cancelled.

b) In case of model 2, the TSP of the Beneficiary (BTSP) informs the Switch of the Bank (in which both the Customer and the Beneficiary have a primary account registered for mobile payments) to inform the TSP of the Customer (CTSP) about the same. The Customer’s TSP now intimates the Customer.

c) In case of model 3, the TSP (Customer and Beneficiary have the same TSP) informs the Switch (S2) of the Bank B2 in which the Beneficiary has the primary account registered for mobile payments which then informs the Centralized Switch (CS) to forward to the Switch (S1) of the Bank in which the Customer has the primary account registered for mobile payments.S1 now informs the Customer’s TSP which then informs the Customer that the transaction has been cancelled.

d) In case of model 4, the TSP of the Beneficiary (BTSP) informs the Switch S2 of the Bank B2 to inform the Central Switch (CS) to forward to switch S1 of Bank B1 that the transaction has been cancelled. S1 now informs the Customer’s TSP (CTSP) which then informs the Customer about the same.

4.2.e Summary

The proposed model, from the above scenarios, gives a greater insight into the Mobile Payments Architecture which can be implemented on a real time basis in the near future as it gives solutions for handling almost all the exceptions that generally arise during the payment process.

CSE,UCE,OU 85 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Chapter 5: CONCLUSION

CSE,UCE,OU 86 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

References Operating Systems 1. Operating System Concepts Seventh Edition by Abraham Silberschatz, Peter Baer Galvin and Greg Gagne. John Wiley & Sons.INC. 2. Operating Systems Uncovered – The Inside Scoops Are Revealed from www.GiveAwayGuides.com

Symbian OS 1. Symbian OS Official Website http://www.symbian.org 2. The Symbian OS Architecture Sourcebook-Design and Evolution of a Mobile Phone OS, by Ben Morris Symbian OS\WileyTheSymbianOSArchitectureSourcebook_2007_.pdf 3. Symbian OS C++ for Mobile Phones by Richard Harrison et al. John Wiley & Sons © 2003. 4. Harrison, R. (2004) Symbian OS C++ for Mobile Phones, Volume 2. Symbian Press 5. Heath, C. (2006) Symbian OS Platform Security. Chichester: John Wiley & Sons 6. Sales, J. (2005) Symbian OS Internals. John Wiley & Sons 7. Stichbury, J. (2005) Symbian OS Explained. John Wiley & Sons 8. Spence, E. (2005) Rapid Mobile Enterprise Development for Symbian OS: An introduction to OPL application design and programming. John Wiley & Sons

Palm OS 1. Bachmann, Glenn. Palm Programming, the Authoritative Solution . Sam’s Publishing, 1999. 2. Rhodes, Neil and Julie McKeehan. Palm Programming, The Developer’s Guide . O’Reilly and Associates, Inc., 1999. 3. Palmsource inc. "Palm OS Programmers Compainion, Volume 1". December 2, 2002 http://www.palmos.com/dev/support/docs/palmos/SystemFeatures.html#1014669

TinyOS 1. www.tinyOS.net 2. http://webs.cs.berkeley.edu/tos/ 3. Get Start with TinyOS, Tian He 4. TinyOS/NesC overview, Crossbow technology Inc. 5. TinySec: Link Layer Security for Tiny Devices. http://www.cs.berkeley.edu/nks/tinysec/ . 6. http://tinyos.millennium.berkeley.edu U.C. Berkeley 11/13/2000

JavaOS

CSE,UCE,OU 87 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

1. JavaOS: A Standalone Java Environment, A White Paper, Peter W. Madany, With contributions by Graham Hamilton and Jim Mitchell. 2. Janos: A Java-Oriented OS for Active Network Nodes Patrick Tullmann, Mike Hibler, and Jay Lepreau IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 19, NO. 3 MARCH 2001. http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F49%2F 19828%2F00917710.pdf&authDecision=-203

SCOSTA 1. http://www.scosta.gov.in 2. Specifications for the Smart-Card Operating System for Transport Applications (SCOSTA),National Informatics Centre, Ministry of Communication and Information Technology, Government of India, Ministry of Road Transport and Highways, Government of India and Indian Institute of Technology, Kanpur. http://scosta.gov.in/SCOSTA_1.pdf 3. Specifications for the Smart-Card Operating System with Contact-less Interface, National Informatics Centre, Ministry of Communication and Information Technology, Government of India and Indian Institute of Technology, Kanpur. http://www.scosta.gov.in/scostaCL.pdf 4. ISO Standards for smart cards http://www.iso.org

MULTOS 1. www.multos.com

Mobile Payments 1. MPFI Interoperability Standard V1.2, Interoperability Standards for Mobile Payments by The MPFI Technology Committee. 2. Mobile Payment Process by Dr. Ashok Jhunjhunwala, IIT-Madras and Mr. G P Shekar, FSS . 3. Mobile Payment Systems and Services: An Introduction by Mahil Carr, IDRBT, Hyderarbad. 4. Presentation on mobile payments by Technology sub-committee, Mobile Payment Forum of India.

J2ME 1. Beginning J2ME : From Novice to Professional , Third Edition by Jonathan Knudsen and Sing Li. 2. J2ME: The Complete Reference by James Keogh. 3. http://java.sun.com/javame/index.jsp

CSE,UCE,OU 88 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Appendix A - J2ME API

CLDC API The CLDC API is really just a subset of the J2SE java.lang, java.io, and java.util packages plus a new package -- javax.microedition. Although each of these classes exists in J2SE, the CLDC implementation of each class does not necessarily implement all methods supported by J2SE. A copy of the documentation is in the j2me_cldc/docs directory of the J2ME CLDC installation. It is available in both PDF and javadoc formats. java.lang The CLDC java.lang package is a subset of the J2SE java.lang package. The most notable omissions compared to J2SE are floating point operations and, in particular, floating point (Float) and double precision (Double) classes. These omissions have implications to all other classes if floating point is used. When compared with J2SE v1.3 API, there are several other classes that are omitted from the CLDC API, including ClassLoader, Compiler, InheritableThreadLocal, Number, Package, Process, RuntimePermission, SecurityManager, StrictMath, ThreadGroup, ThreadLocal, and Void. The Runnable interface is supported by CLDC, as are the Exception, Error and related classes. java.lang core run-time classes The core run-time classes for the java.lang package are: * Class -- Represents classes and interfaces in a running Java application. * Object -- As in J2SE, Object is the base class of all Java objects. * Runtime -- Provides a way for a Java application to interact with the run-time environment in which it is running. * System -- Provides several static helper methods, as with J2SE. * Thread -- Defines a thread of execution for a Java program. * Throwable -- The superclass of all errors and exceptions in the Java language. java.lang core data type classes The core data type classes in the java.lang packages are: * Boolean -- Wraps the boolean primitive data type. * Byte -- Wraps the byte primitive data type. * Character -- Wraps the char primitive data type. * Integer -- Wraps the int primitive data type. * Long -- Wraps the long primitive data type. * Short -- Wraps the short primitive data type.

CSE,UCE,OU 89 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

java.lang helper classes The helper classes for the java.lang package are: * Math -- Contains methods for performing basic mathematical operations. Note that all the methods manipulating floating point values are omitted, leaving only the abs(), min(), and max() methods on integers and longs. * String -- Represents String objects in Java, as in J2SE. * StringBuffer -- Represents a string that can be modified, as in J2SE. java.io input classes The CLDC API contains many of the commonly used input classes from J2SE. In particular, the CLDC java.io package includes the following classes: * ByteArrayInputStream -- Contains an internal buffer representing bytes that may be read from an input stream. * DataInput -- An interface that provides for reading bytes from a binary input stream and translating them into primitive Java data types. DataInputStream provides an implementation of this interface. * DataInputStream -- Allows an application to read primitive Java data types from the underlying input stream in a platform-independent way. * InputStream -- An abstract class that is the superclass of all classes representing an input stream of bytes. * InputStreamReader -- Reads bytes and translates them into characters according to a specified character encoding. * Reader -- An abstract class for reading character streams. As with the java.lang package, some of these classes may not contain all the methods supported by their J2SE cousin. In particular, the floating point and double precision methods are omitted. java.io output classes The CLDC API contains many of the commonly used output classes from J2SE. In particular, the CLDC java.io package includes the following output classes: * ByteArrayOutputStream -- Implements an output stream where data is written into a bytes array. * DataOutput -- An interface that provides for writing primitive Java data types to a binary output stream. DataOutputStream provides an implementation of this interface. * DataOutputStream -- An output stream that allows an application to write primitive Java data types in a portable way. * OutputStream -- An abstract class that is the superclass of all classes representing an output stream of bytes. * OutputStreamReader -- Given characters, translates them into bytes according to a specified character encoding. * PrintStream -- Adds a convenient way to print a textual representation of data values. * Writer -- An abstract class for writing character streams. Some of these classes may not contain all the methods supported by J2SE, such as the floating point and double precision methods. java.util collections classes

CSE,UCE,OU 90 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

The CLDC java.util package contains the most frequently used classes from the J2SE java.util package. These include four of the collections classes -- actually three classes and one interface -- as well as date/time and utility classes. The java.util collections classes supported by CLDC are: * Enumeration -- An interface that allows the calling routine to iterate through a collection of items, one at a time. * Hashtable -- Implements a hashtable, which maps keys to values. * Stack -- Represents a last-in-first-out (LIFO) collection or stack of objects. * Vector -- Represents a resizable "array," or vector, of objects. java.util -- other classes The remaining java.util classes supported by CLDC include date and time classes and the Random utility class. These are summarized in the following table. * Calendar -- An abstract class for getting and setting dates using a set of integer fields such as YEAR, MONTH, DAY, and so on. * Date -- Represents a specific date and time, with millisecond precision. * Random -- Utility class used to generate a stream of random int or long values. * TimeZone -- Represents a time zone offset, and also handles daylight savings adjustments. javax.microedition.io So far, all the classes in the CLDC API have been a subset of the J2SE API. CLDC also includes one additional package -- the javax.microedition.io package. The only class defined in this package is the Connector class, a factory class that contains methods to create Connection objects, or input and output streams. Connection objects are created when a class name is identified dynamically. A class name is identified based on the platform name, as well as the protocol of the requested connection. The parameter string that describes the target adheres to the URL format required by the RFC 2396 specifications . Use the following format: {scheme}:[{target}][{params}] The {scheme} is the name of a protocol such as http or ftp. {target} is usually a network address, but non- network oriented protocols may treat this as a fairly flexible field. Any parameters, {params}, are specified as a series of assignments of the form ";x=y" (for example, ;myParam=value). javax.microedition.io helper interfaces In addition to the generic connection factory class, the javax.microedition.io package also contains the following connection-oriented interfaces: * Connection -- Defines the most basic type of connection. This interface is also the base class for all other connection interfaces in this package. * ContentConnection -- Defines a stream connection over which content is passed. * Datagram -- Defines a generic datagram interface. * DatagramConnection -- Defines a generic datagram connection and the capabilities it must support. * InputConnection -- Defines a generic input stream connection and the capabilities that it must support. * OutputConnection -- Defines a generic output stream connection and the capabilities that it must support. * StreamConnection -- Defines a generic stream connection and the capabilities that it must support.

CSE,UCE,OU 91 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

* StreamConnectionNotifier -- Defines the capabilities that a stream connection notifier must have.

MIDP API

MIDP encompasses the four core CLDC packages (java.lang, java.io, javax.microedition.io and java.util,), plus the following three MIDP-specific packages: * javax.microedition.lcdui * javax.microedition.midlet * javax.microedition.rms

In addition to the above new packages, MIDP also adds four new classes, shown below, to the core CLDC packages. * java.util.Timer -- Used to schedule tasks for future execution in a background thread. * java.util.TimerTask-- Used by the java.util.Timer class to define tasks for later execution in a background thread. * javax.microedition.io.HttpConnection-- An interface that defines the necessary methods and constants for an HTTP connection. * java.lang.IllegalStateException-- A RuntimeException that indicates that a method has been invoked at an illegal or inappropriate time.

CSE,UCE,OU 92 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

APPENDIX B - J2ME CODE FOR MOBILE PAYMENTS PUSH MODEL (MAKING A PAYMENT)

UI for Customer import javax.microedition.lcdui.*; import javax.microedition.midlet.*; import javax.microedition.lcdui.TextField; import java.util.Date; import java.util.TimeZone; import java.io.*; import javax.microedition.io.*; public class Customer extends MIDlet implements CommandListener { private Form form,f1,f2,f3,f11; private Display display; private TextField mobilenumber,amnt,text; private Command ok,cancel,back,exit,proceed,verify; private Command hom,continu,next,start,done; private Ticker ticker; private DateField date1; StringItem m; private Image img; String mn,amt,p=null; private List l,l1;

public Customer() { mobilenumber=new TextField("Mobile Number : ","",10,TextField.PHONENUMBER); amnt=new TextField("Amount in Rs. you would like to pay : ","",10,TextField.NUMERIC); ok=new Command("OK",Command.OK,2); m=new StringItem(null,""); cancel=new Command("Cancel",Command.CANCEL,2); exit=new Command("Exit",Command.EXIT,0);

CSE,UCE,OU 93 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

proceed=new Command("Proceed",Command.SCREEN,2); next=new Command("Next",Command.OK,0); String elements[]={"Game 1","Mobile Payments Application","Game 2","Digital Clock"}; l=new List("Applications",List.IMPLICIT,elements,null); back=new Command("Back",Command.BACK,0); done=new Command("Done",Command.SCREEN,0); String ele[]={"Select one from the List of Transactions","Make a Payment","Know my Balance","Transaction History"}; l1=new List("You are an authorized user.. ",List.IMPLICIT,ele,null);

} public void startApp() { display=Display.getDisplay(this); Form f1=new Form("Your Applications"); l.addCommand(next); l.addCommand(exit); l.setCommandListener(this); display.setCurrent(l); }

public void pauseApp() { }

public void destroyApp(boolean unconditional) { notifyDestroyed(); }

public void showNext() { display=Display.getDisplay(this); Form form1=new Form("Requesting for payment -- PUSH model"); mn=mobilenumber.getString(); amt=amnt.getString(); String you="You have entered the following \n"; you=you+" mobile number : "+mn; you = you+"\n amount : Rs."+amt; form1.append(you); int indplus=mn.indexOf('+');

CSE,UCE,OU 94 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

int indstar=mn.indexOf('*'); int indhash=mn.indexOf('#'); String num="9908648106"; if(mn.length() < 10 || (indplus>=0 && indplus=0 && indstar=0 && indhash

public void cancel_function() { display.setCurrent(form); }

public void commandAction(Command c,Displayable d)

CSE,UCE,OU 95 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

{ try { String label=c.getLabel(); if(label.equals("Back")) { display.setCurrent(l1); } if(label.equals("Next")) { int index=l.getSelectedIndex(); String nam=l.getString(index); System.out.println(" nam = "+nam+" index= "+index); if(nam.equals("Mobile Payments Application")) { f2=new Form("Authentication!!"); verify=new Command("Verify",Command.SCREEN,0); StringItem x= new StringItem("",null); f2.append(x); x.setText("Please enter your 6 digit pin and click Verify"); text=new TextField("Enter PIN : ","",6,TextField.PASSWORD); f2.append(text); f2.addCommand(exit); f2.addCommand(verify); f2.setCommandListener(this); display.setCurrent(f2); } } if(label.equals("Verify")) { p=text.getString(); if(p.length()==0) { String y="Please enter the pin number in order to proceed"; f2.append(y); display.setCurrent(f2); } else if(p.length()<6) {

CSE,UCE,OU 96 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

String z ="you have to enter a 6 digit pin number"; f2.append(z); display.setCurrent(f2); } else { Form f3=new Form("Authenticating..."); String x="Please Wait.."; f3.append(x); display.setCurrent(f3); Thread t = new Thread() { public void run() { connect2(); } }; t.start(); } } if(label.equals("OK")) { showNext(); } if(label.equals("Start")) { int index=l1.getSelectedIndex(); String nam=l1.getString(index); System.out.println(" nam = "+nam+" index= "+index); if(nam.equals("Make a Payment")) { form=new Form("Mobile Payments -- PUSH MODEL"); ticker=new Ticker(" Welcome to the Mobile Payments Application"); form.setTicker(ticker); String hello ="If you would like to initiate a payment transaction,please enter the beneficiary mobile number, the amount you would like to pay and then Click OK,otherwise click Cancel"; form.append(hello); form.append(mobilenumber);

CSE,UCE,OU 97 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

form.append(amnt); form.addCommand(back); form.addCommand(ok); form.setCommandListener(this); display.setCurrent(form); } } if(label.equals("Cancel")) { cancel_function(); } if(label.equals("Exit")) { destroyApp(true); } if(label.equals("Proceed")) { try { Form process=new Form("Progress.."); StringItem si=new StringItem(null,"Processing your request...This may take few seconds"); process.append(si); display.setCurrent(process); Thread t = new Thread() { public void run() { connect1(); } }; t.start(); } catch(Exception e) { e.printStackTrace(); } } if(label.equals("Home")) { display.setCurrent(form); } if(label.equals("Continue")) {

CSE,UCE,OU 98 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Form f8=new Form("Processing your request.."); String x="Checking whether there is sufficient balance in your account to make the payment"; f8.append(x); display.setCurrent(f8); Thread t = new Thread() { public void run() { connect4(); } }; t.start(); } if(label.equals("Done")) { f11=new Form("Making the payment"); String x="Please wait...the transaction is being made"; f11.append(x); Thread t= new Thread() { public void run() { connect6(); } }; t.start(); } } catch(Exception e) { e.printStackTrace(); } } public void connect1() { HttpConnection hc = null; InputStream in = null; OutputStream out=null; String message="mnumber="+mn; String url = "http://localhost:8080/MobilePayments/ProcessingServlet"+"? "+"mnumber="+mn+"&"+"amount="+amt; try

CSE,UCE,OU 99 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

{ hc = (HttpConnection)Connector.open(url); hc.setRequestMethod(HttpConnection.GET); out=hc.openOutputStream(); out.write(message.getBytes()); in = hc.openInputStream(); int contentLength = (int)hc.getLength(); byte[] raw = new byte[contentLength]; int length = in.read(raw); in.close(); hc.close(); String s = new String(raw, 0, length); m.setText(s); } catch (Exception ioe) { m.setText(ioe.toString()); } Form f=new Form("details.."); f.append(m); hom=new Command("Home",Command.OK,0); continu=new Command("Continue",Command.SCREEN,1); f.addCommand(hom); f.addCommand(continu); f.addCommand(exit); f.setCommandListener(this); display.setCurrent(f); } public void connect2() { HttpConnection hc=null; InputStream in=null; OutputStream out=null; String num="9908648106"; String url = "http://localhost:8080/MobilePayments/AuthenticationServlet "+"?"+"num="+num+"&"+"pin="+p; String message="pin="+p; try { hc = (HttpConnection)Connector.open(url); hc.setRequestMethod(HttpConnection.GET); out=hc.openOutputStream(); out.write(message.getBytes()); in = hc.openInputStream();

CSE,UCE,OU 100 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

int contentLength = (int)hc.getLength(); byte[] raw = new byte[contentLength]; int length = in.read(raw); in.close(); hc.close(); String s = new String(raw,0,3); m.setText(s); if(s.equals("noo")) { Form f4=new Form("Not an Authorized Customer"); String x="Sorry! you are not an authorized Cusotmer of the Application and so click Exit"; f4.append(x); f4.addCommand(exit); f4.setCommandListener(this); display.setCurrent(f4); } else if(s.equals("yes")) { Form f7=new Form("you are an authorized user.."); String m="Checking your account details.."; f7.append(m); display.setCurrent(f7); Thread t = new Thread() { public void run() { connect3(); } }; t.start(); } } catch(Exception e) { e.printStackTrace(); Form f5=new Form("Connection problem"); String x="There is some problem with the network connection,please check your connection and try again"; f5.append(x); f5.addCommand(exit); f5.setCommandListener(this); display.setCurrent(f5); }

CSE,UCE,OU 101 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

} public void connect3() { HttpConnection hc1=null; InputStream in1=null; OutputStream out1=null; String num="9908648106"; String url1 = "http://localhost:8080/MobilePayments/CheckingServlet"+"?"+ "num="+num; String message1="num="+num; try { hc1 = (HttpConnection)Connector.open(url1); hc1.setRequestMethod(HttpConnection.GET); out1=hc1.openOutputStream(); out1.write(message1.getBytes()); in1 = hc1.openInputStream(); int contentLength1 = (int)hc1.getLength(); byte[] raw1 = new byte[contentLength1]; int length1 = in1.read(raw1); in1.close(); hc1.close(); String s2 = new String(raw1,0,3); if(s2.equals("yes")) { start=new Command("Start",Command.OK,0); l1.addCommand(start); l1.addCommand(exit); l1.setCommandListener(this); display.setCurrent(l1); } else if(s2.equals("noo")) { Form f6=new Form("No Account.."); String e2="You do not have a bank account registered with this mobile number,so click Exit"; f6.append(e2); f6.addCommand(exit); f6.setCommandListener(this); display.setCurrent(f6); } } catch(Exception e)

CSE,UCE,OU 102 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

{ e.printStackTrace(); Form f5=new Form("Connection problem"); String e1="There is some problem with the network connection,please check your connection and try again"; f5.append(e1); f5.addCommand(exit); f5.setCommandListener(this); display.setCurrent(f5); } } public void connect4() { HttpConnection hc=null; InputStream in=null; OutputStream out=null; String num="9908648106"; String url = "http://localhost:8080/MobilePayments/BalanceServlet"+"?"+" num="+num+"&"+"amount="+amt; String message="num="+num; try { hc = (HttpConnection)Connector.open(url); hc.setRequestMethod(HttpConnection.GET); out=hc.openOutputStream(); out.write(message.getBytes()); in = hc.openInputStream(); int contentLength = (int)hc.getLength(); byte[] raw = new byte[contentLength]; int length = in.read(raw); in.close(); hc.close(); String s = new String(raw,0,3); m.setText(s);

if(s.equals("noo")) { Form f8=new Form("No Sufficient balance "); String x="There is no sufficient balance in your account to make a payment"; f8.append(x); f8.addCommand(exit); f8.setCommandListener(this);

CSE,UCE,OU 103 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

display.setCurrent(f8); } else if(s.equals("yes")) { Form f9=new Form("You have sufficient balance in your account to make a payment"); String m="Checking whether the beneficiary is ready to accept your payment.."; f9.append(m); display.setCurrent(f9);

Thread t = new Thread() { public void run() { connect5(); } }; t.start(); } } catch(Exception e) { e.printStackTrace(); Form f5=new Form("Connection problem"); String x="There is some problem with the network connection,please check your connection and try again"; f5.append(x); f5.addCommand(exit); f5.setCommandListener(this); display.setCurrent(f5); } } public void connect5() { HttpConnection hc1=null; InputStream in1=null; OutputStream out1=null; String num="9908648106"; String url1 = "http://localhost:8080/MobilePayments/BeneficiaryServlet";/ /+"?"+"num="+num+"&"+"amount="+amt; String message1="num="+num;

CSE,UCE,OU 104 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

try {

hc1 = (HttpConnection)Connector.open(url1); hc1.setRequestMethod(HttpConnection.GET); in1 = hc1.openInputStream(); int contentLength1 = (int)hc1.getLength(); byte[] raw1 = new byte[contentLength1]; int length1 = in1.read(raw1); in1.close(); hc1.close(); String s2 = new String(raw1,0,3); System.out.println(s2); if(s2.equals("yes")) { Form f10=new Form("Willing.."); String x="Beneficiary is willing to accept your payment,If you wish to pay now,click Done,otherwise click Exit"; f10.append(x); f10.addCommand(done); f10.addCommand(exit); f10.setCommandListener(this); display.setCurrent(f10); } else if(s2.equals("noo")) { Form f6=new Form("Not Willing.."); String e2="Beneficiary is not willing to accept your payment,click Exit to Quit"; f6.append(e2); f6.addCommand(exit); f6.setCommandListener(this); display.setCurrent(f6); } } catch(Exception e) { e.printStackTrace(); Form f5=new Form("Connection problem"); String e1="There is some problem with the network connection,please check your connection and try again"; f5.append(e1); f5.addCommand(exit);

CSE,UCE,OU 105 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

f5.setCommandListener(this); display.setCurrent(f5); } } public void connect6() { HttpConnection hc = null; InputStream in = null; OutputStream out=null; String message="mnumber="+mn; String url= "http://localhost:8080/MobilePayments/DoneServlet"+"?"+"mnu mber="+mn+"&"+"amount="+amt; try { hc = (HttpConnection)Connector.open(url); hc.setRequestMethod(HttpConnection.GET); out=hc.openOutputStream(); out.write(message.getBytes()); in = hc.openInputStream(); int contentLength = (int)hc.getLength(); byte[] raw = new byte[contentLength]; int length = in.read(raw); in.close(); hc.close(); String s = new String(raw, 0, length); Form f12=new Form("details.."); StringItem m1=new StringItem(null,""); m1.setText(s); f12.append(m1); f12.addCommand(exit); f12.setCommandListener(this); display.setCurrent(f12); } catch (Exception ioe) { ioe.printStackTrace(); } }

}

UI FOR BENEFICAIRY

CSE,UCE,OU 106 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009 import javax.microedition.lcdui.*; import javax.microedition.midlet.*; import java.io.*; import javax.microedition.io.*; public class Ben extends MIDlet implements CommandListener { private Command exit,yes,no,accept; private Form f,f2; private Display display; private Ticker ticker; public Ben() { try { yes=new Command("YES",Command.SCREEN,1); no=new Command("No",Command.OK,0); exit=new Command("Exit",Command.EXIT,0); accept=new Command("View",Command.SCREEN,0); } catch(Exception e) { e.printStackTrace(); } }

public void startApp() { try { display=Display.getDisplay(this); f=new Form("Message"); String x="There is a payment offer for you,click View if you wish to accept otherwise click exit"; f.append(x); f.addCommand(exit); f.addCommand(accept); f.setCommandListener(this); display.setCurrent(f); } catch(Exception e) { e.printStackTrace(); } }

CSE,UCE,OU 107 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

public void pauseApp() { }

public void destroyApp(boolean unconditional) { notifyDestroyed(); }

public void commandAction(Command c,Displayable d) { String label=c.getLabel(); System.out.println("2"); if(label.equals("Exit")) { destroyApp(true); } if(label.equals("View")) { f2=new Form("Opening the Message"); display.setCurrent(f2); Thread t= new Thread() { public void run() { connect1(); } }; t.start(); } if(label.equals("YES")) { Form f3=new Form("willing to Receive Payment.."); String x="You will shortly receive the payment"; f3.append(x); System.out.println("5"); display.setCurrent(f3); Thread t= new Thread() { public void run() { connect2(); } };

CSE,UCE,OU 108 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

t.start(); } if(label.equals("No")) { Form f3=new Form("Not willing to Receive Payment"); String x="It will be intimated to the customer that you have cancelled the transaction. click Exit to quit"; f3.append(x); Thread t= new Thread() { public void run() { connect3(); } }; t.start(); f3.addCommand(exit); f3.setCommandListener(this); display.setCurrent(f3); } }

public void connect1() { HttpConnection hc = null; InputStream in = null; String s=null; String url= "http://localhost:8080/MobilePayments/AcceptanceServlet"; try { hc = (HttpConnection)Connector.open(url); hc.setRequestMethod(HttpConnection.GET); in = hc.openInputStream(); int contentLength = (int)hc.getLength(); byte[] raw = new byte[contentLength]; int length = in.read(raw); in.close(); hc.close(); s = new String(raw, 0, length); } catch (Exception ioe) { ioe.printStackTrace();

CSE,UCE,OU 109 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

} f2.append(s); f2.addCommand(yes); f2.addCommand(no); f2.setCommandListener(this); }

public void connect2() { HttpConnection hc = null; InputStream in = null; String url= "http://localhost:8080/MobilePayments/PaymentServlet"; try { hc = (HttpConnection)Connector.open(url); hc.setRequestMethod(HttpConnection.GET); in = hc.openInputStream(); int contentLength = (int)hc.getLength(); byte[] raw = new byte[contentLength]; int length = in.read(raw); in.close(); hc.close(); String s = new String(raw, 0, length); System.out.println("3"); Form f4=new Form("Recieved Payment"); f4.append(s); f4.addCommand(exit); f4.setCommandListener(this); display.setCurrent(f4); } catch (Exception ioe) { ioe.printStackTrace(); } } public void connect3() { HttpConnection hc = null; InputStream in = null; String url= "http://localhost:8080/MobilePayments/CancelServlet"; try { hc = (HttpConnection)Connector.open(url);

CSE,UCE,OU 110 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

hc.setRequestMethod(HttpConnection.GET); in = hc.openInputStream(); int contentLength = (int)hc.getLength(); byte[] raw = new byte[contentLength]; int length = in.read(raw); in.close(); hc.close(); String s = new String(raw, 0, length); } catch (Exception ioe) { ioe.printStackTrace(); } } }

BACKEND FOR THE APPLICATION

CMPP Account in MobileNumber Name Address AccountNumber Balance Bank 9876541245 avanthi uppal sbi 246238 8500 9876783459 manasa vidyanagar andhrabank 876543 8500 9908648106 vv hmt sbh 586344 88600

BMPP MobileNumber Name Address Account in Bank AccountNumber Balance 9966332255 aishwarya himayathnagar ICICI 123456 40900 9876541245 avanthi uppal sbi 246238 18500 9876783459 manasa vidyanagar andhrabank 876543 5500

Decision Decision yes

Transaction MobileNumber Amount 9908648106 1000

CSE,UCE,OU 111 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Transaction1 MobileNumber Amount 9908648106 1000

SERVLETS AuthenticationServlet.java import java.io.*; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.sql.*; public class AuthenticationServlet extends HttpServlet { Connection con=null; Statement st=null; ResultSet rst=null; PreparedStatement pst=null;

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); PrintWriter out = response.getWriter(); try { String pinnum=request.getParameter("pin"); String mobnum=request.getParameter("num"); Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); con= DriverManager.getConnection("jdbc:odbc:pinverification "); st=con.createStatement(); rst=st.executeQuery("select * from Pin"); int x=0; if(rst.next()) { do {

CSE,UCE,OU 112 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

String num=rst.getString(1); if(mobnum.equals(num)) { String pin=rst.getString(2); if(pin.equals(pinnum)) { String s="yes"; response.set ContentLength(s.length()); out.println(s); x=1; } } }while(rst.next()); } if(x==0) { String s="noo"; response.setContentLength(s.length()); out.println(s); } } catch(Exception e) { out.println(e.toString()); } } }

BalanceServlet.java import java.io.*; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.sql.*; import javax.servlet.RequestDispatcher;

public class BalanceServlet extends HttpServlet { Connection con=null; Statement st=null;

CSE,UCE,OU 113 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

ResultSet rst=null; PreparedStatement pst=null; protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); PrintWriter out = response.getWriter(); try { String mnum=request.getParameter("num"); String amt=request.getParameter("amount"); Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); con=DriverManager.getConnection("jdbc:odbc:MPP"); st=con.createStatement(); st.execute("DROP TABLE Transaction"); st.execute("CREATE TABLE Transaction (MobileNumber Text,Amount Text)"); pst=con.prepareStatement("INSERT INTO Transaction"+"(MobileNumber,Amount)"+" VALUES (?,?)"); pst.setString(1,mnum); pst.setString(2,amt); pst.execute(); st.execute("DROP TABLE Transaction1"); st.execute("CREATE TABLE Transaction1 (MobileNumber Text,Amount Text)"); pst=con.prepareStatement("INSERT INTO Transaction1"+"(MobileNumber,Amount)"+" VALUES (?,?)"); pst.setString(1,mnum); pst.setString(2,amt); pst.execute(); rst=st.executeQuery("SELECT * from CMPP"); int x=0; String name; Double bal; if(rst.next()) { do { String num=rst.getString(1); double a= Double.parseDouble(rst.getString(6)); double amount=Double.parseDouble(amt); if(num.equals(mnum))

CSE,UCE,OU 114 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

{ if(a<=(amount+500)) { x=1; String s="noo"; response.set ContentLength(s.length()); out.println(s); } } }while(rst.next()); } if(x==0) { String s="yes"; response.setContentLength(s.length()); out.println(s); } } catch(Exception e) { out.println(e.toString()); } } }

BeneficiaryServlet.java import java.io.IOException; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.sql.*; import javax.servlet.RequestDispatcher; public class BeneficiaryServlet extends HttpServlet { Connection con=null; Statement st=null; ResultSet rst=null; PreparedStatement pst=null; public void doGet(HttpServletRequest request,HttpServletResponse response)throws IOException,ServletException

CSE,UCE,OU 115 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

{ response.setContentType("text/plain"); PrintWriter out = response.getWriter(); try {

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); con=DriverManager.getConnection("jdbc:odbc:MPP"); st=con.createStatement(); st.execute("DROP TABLE Decision"); st.execute("CREATE TABLE Decision(Decision Text)"); try { Thread.sleep(7000); } catch(Exception e) { out.println("1"+e.toString()); } rst=st.executeQuery("select * from Decision"); if(rst.next()) { String s=rst.getString(1); response.setContentLength(s.length()); out.println(s); System.out.println("sent to customer = "+s); } } catch(Exception e) { out.println(e.toString()); } } }

CheckingServlet.java import java.io.*; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.sql.*;

CSE,UCE,OU 116 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

public class CheckingServlet extends HttpServlet { Connection con=null; Statement st=null; ResultSet rst=null; PreparedStatement pst=null; protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain");

PrintWriter out = response.getWriter(); try { String num=request.getParameter("num"); Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); con=DriverManager.getConnection("jdbc:odbc:MPP"); st=con.createStatement(); rst=st.executeQuery("select * from CMPP"); int x=0; if(rst.next()) { do { String numdb=rst.getString(1); String bname=rst.getString(4); String bnum=rst.getString(5); if(numdb.equals(num)) { String s="yes"; response.set ContentLength(s.length()); out.println(s); x=1; } }while(rst.next()); } if(x==0) { String s="noo"; response.setContentLength(s.length()); out.println(s); }

CSE,UCE,OU 117 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

} catch(Exception e) { out.println(e.toString()); } } }

DoneServlet.java import java.io.*; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.sql.*; public class DoneServlet extends HttpServlet { Connection con=null; Statement st=null; ResultSet rst=null,rst1=null,rst2=null; PreparedStatement pst=null,pst1=null; int x=0; double y; protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ response.setContentType("text/plain"); PrintWriter out = response.getWriter(); try { String mnum=request.getParameter("mnumber"); double amt=Double.parseDouble(request.getParameter("amount")); Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); con=DriverManager.getConnection("jdbc:odbc:MPP"); st=con.createStatement(); rst=st.executeQuery("select * from CMPP"); String num="9908648106"; if(rst.next()) { do {

CSE,UCE,OU 118 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

String cnum=rst.getString(1); double ca=Double.parseDouble(rst.getString(6)); if(num.equals(cnum)) { rst1=st.executeQuery("select * from BMPP"); if(rst1.next()) { do { String bnum= rst1.getString(1); if(bnum.equals(mnum)) { double ba= Double.parseDouble(rst1.get String(6)); ba=ba+amt; ca=ca-amt; pst= con.prepareStatement("UPDAT E BMPP SET Balance=? WHERE MobileNumber LIKE ? "); pst.setDouble(1,ba); pst.setString(2,mnum); pst.executeUpdate(); pst1= con.prepareStatement("UPDAT E CMPP SET Balance=? WHERE MobileNumber LIKE ? "); pst1.setDouble(1,ca); pst1.setString(2,num); pst1.executeUpdate(); x=1; rst2= st.executeQuery("SELECT * FROM CMPP"); if(rst2.next()) { do { y= Double.parseDouble(rs t2.getString(6)); cnum= rst2.getString(1);

CSE,UCE,OU 119 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

if(cnum.equals(num)) { String s="Updated your account.You Paid Rs. "+amt+" to Mobile Number : "+mnum; s=s+". Your Current Balance = Rs. "+y; response.setContentLe ngth(s.length()); out.println(s); } }while(rst2.next()); } } }while(rst1.next()); } } }while(rst.next()); } if(x!=1) { String s="There was some problem in making the payment,please try again later"; response.setContentLength(s.length()); out.println(s); }

} catch(Exception e) { e.printStackTrace(); } } }

ProcessingServlet.java import java.io.*; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse;

CSE,UCE,OU 120 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009 import java.sql.*; public class ProcessingServlet extends HttpServlet {

Connection con=null; Statement st=null; ResultSet rst=null; PreparedStatement pst=null; protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ response.setContentType("text/plain"); PrintWriter out = response.getWriter(); try { String mnum=request.getParameter("mnumber"); double amt= Double.parseDouble(request.getParameter("amount")); Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); con=DriverManager.getConnection("jdbc:odbc:MPP"); st=con.createStatement();

rst=st.executeQuery("select * from CMPP"); int x=0; String name; Double bal; if(rst.next()) { do { String num=rst.getString(1); double a=Double.parseDouble(rst.getString(6)); if(num.equals(mnum)) { name=rst.getString(2); x=1;

String s="Name : "+name+"\n"+"Mobile Number :"+mnum+"\nAmount you wish to pay : Rs. "+amt+"\n"; s=s+"If correct,click continue for further processing\n"; response.setContentLength(s.length()); out.println(s);

CSE,UCE,OU 121 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

} }while(rst.next()); } if(x==0) { out.println("The entered Mobile Number does not have a corresponding account registered,so click exit to stop the transaction"); } } catch(Exception e) { out.println(e.toString()); } } }

AcceptanceServlet.java import java.io.*; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.sql.*; import javax.servlet.RequestDispatcher; public class AcceptanceServlet extends HttpServlet { Connection con=null; Statement st=null; ResultSet rst=null; protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ response.setContentType("text/plain"); PrintWriter out = response.getWriter(); try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); con=DriverManager.getConnection("jdbc:odbc:MPP"); st=con.createStatement(); rst=st.executeQuery("select * from Transaction");

CSE,UCE,OU 122 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

if(rst.next()) { String num=rst.getString(1); String amt=rst.getString(2); String s="Do you wish to accept a payment of Rs. "+amt+" from Mobile Number : "+num+" ? "; response.setContentLength(s.length()); out.println(s); } } catch(Exception e) { out.println(e.toString()); } } }

CancelServlet.java import java.io.IOException; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.sql.*; import javax.servlet.RequestDispatcher; public class CancelServlet extends HttpServlet { Connection con=null; Statement st=null; ResultSet rst=null; PreparedStatement pst=null; public void doGet(HttpServletRequest request,HttpServletResponse response)throws IOException,ServletException { response.setContentType("text/plain"); PrintWriter out = response.getWriter(); try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); con=DriverManager.getConnection("jdbc:odbc:MPP"); st=con.createStatement(); String x="INSERT INTO Decision VALUES ('noo') ";

CSE,UCE,OU 123 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

st.executeUpdate(x); } catch(Exception e) { out.println(e.toString()); } } }

PaymentServlet.java import java.io.IOException; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.sql.*; import javax.servlet.RequestDispatcher; public class PaymentServlet extends HttpServlet { Connection con=null; Statement st=null; ResultSet rst=null; PreparedStatement pst=null; public void doGet(HttpServletRequest request,HttpServletResponse response)throws IOException,ServletException { response.setContentType("text/plain"); PrintWriter out = response.getWriter(); try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); con=DriverManager.getConnection("jdbc:odbc:MPP"); st=con.createStatement(); String x="INSERT INTO Decision VALUES ('yes') "; st.executeUpdate(x); rst=st.executeQuery("select * from Transaction1"); String amt=null,num=null; if(rst.next()) { amt=rst.getString(2); num=rst.getString(1);

CSE,UCE,OU 124 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

String y="You have Received Rs. "+amt+" from "+num; y=y+". Click Exit to quit"; response.setContentLength(y.length()); out.println(y); } else { String y="Encountered a problem!!!"; response.setContentLength(y.length()); out.println(y); } } catch(Exception e) { out.println(e.toString()); } } }

CSE,UCE,OU 125 IDRBT

Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009

Screen Shot:

CSE,UCE,OU 126 IDRBT