Battery Optimizer for Android Mobile Devices

In the growing world of technology, cellular devices have quickly emerged as one of the fastest evolving fields. They have increased greatly in both popularity and complexity, requiring more advanced operating systems and applications to meet the demands of the consumer. Android is a software stack designed to meet these demands in an open source environment. The project is currently being developed and funded by the Open Handset Alliance, which includes companies such as Google and T-Mobile.

Android includes an operating system, middleware, and key applications, as well as a Software Development Kit (SDK) for developers to create their own applications for the Android environment. Due to its open source license and tools provided, Android is an ideal platform for bringing the mobile market to the educational realm. This paper describes in detail what Android is, its architecture, and why developers should choose

Android to develop in a mobile de-vice platform environment. The paper also discusses the basic hardware requirements for porting the current version of Android to real hardware.

Android supports its own Power Management (on top of the standard Linux Power Management) designed with the premise that the CPU shouldn't consume power if no applications or services require power. Android requires that applications and services request CPU resources with "wake locks" through the Android application framework and native Linux libraries. If there are no active wake locks, Android will shut down the CPU.

In our proposed system those handy applications like Bluetooth, WI-Fi will get turn-off automatically when the battery percentage reach to a certain point. So users don’t have to bother about to turn-off these applications when they are not in use. The Android Framework exposes power management to services and applications through the Power Manager class.

Applications

Android will ship with a set of core applications including an email client, SMS program, calendar, maps, browser, contacts, and others. All applications are written using the Java programming language.

Application Framework

Developers have full access to the same framework APIs used by the core applications. The application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user.

Underlying all applications is a set of services and systems, including:

• A rich and extensible set of Views that can be used to build an application, including lists, grids, text boxes, buttons, and even an embeddable web browser

• Content Providers that enable applications to access data from other applications (such as Contacts), or to share their own data

• A Resource Manager, providing access to non-code resources such as localized strings, graphics, and layout files

• A Notification Manager that enables all applications to display custom alerts in the status bar

• An Activity Manager that manages the lifecycle of applications and provides a common navigation back stack

Objectives

The objective is to save the battery power to make our mobile alive for a long period. Let us look at the power consumption by the applications like Bluetooth, WI-FI and Brightness.

Flight mode 20% - the basic power consumption when almost all functionality is turned off.

Brightness – it takes 20% when it used at maximum and on average 10-12% .

Wi-Fi - 8% when turned on but not actively used and 13% when turned being actively used.

Bluetooth - 4% when it is not actively used.10% when it is actively used. If the total is 100% it represents that the battery is drained at the maximum possible speed. Hence we can save the power from 30% up to 50% approx.

Highlights of the Project

The technology used here in Android 2.1 platform. We already had Android’s earlier versions. But Android 2.1 is a minor platform release deployable to Android-powered handsets starting in January 2010. This release includes new API changes and bug fixes. For information on changes. For developers, the Android 2.1 platform is available as a downloadable component for the Android SDK. The downloadable platform includes a fully compliant Android library and system image, as well as a set of emulator skins, sample applications, and more. The downloadable platform includes no external libraries.

System Specification

The hardware and software requirements for the development phase of our project are:

Software Requirements :

• Windows XP (32-bit) or Vista (32- or 64-bit)

• Mac OS X 10.4.8 or later (x86 only)

• Linux (tested on Linux Ubuntu Hardy Heron)

• 64-bit distributions must be capable of running 32-bit applications.

Hardware Requirements :

• Although the source code for Android has not been officially released, it is still possible to port Android to real hardware.

• By using a compiled Linux kernel and applying the necessary Android patches, one can port Android to a real device and run a version of Android on the device. .

• Android is currently very hardware specific and when choosing a device to port to, one must abide by the minimum hardware requirements. Since Google has not released the source code to Android, only code available in the SDK can be used.

• The SDK itself uses an open source processor emulator, known as QEMU.

DEMOS Online Quiz

DEMOS ONLINE QUIZ is Windows based web application for facilitating quizzes on any subject based on the data provided to the application. This will be a data driven application whose behavior is mostly controlled by the data provided to this application which makes the application very flexible and powerful.

The features are:

• The application will list, the available subjects of quizzes to the end user where the user can select and execute the Quiz.

• The selected Quiz will have its own characteristics such as total number of questions, marks for each correct answer.

• A new quiz can be added to the system by proving the Quiz data.

Types Of Users

• Administrator: Person who is granted access to database.

The functions of administrator are:

• Add or edit Subjects

• Add or edit Questions

• Check the status of the on-going quiz

• Adds new participants and keep their details

• Controls registration of participants

• Add new News about the site

• Keeps the Login History

• Participants : These are the users who participate in the quiz competition .Each user has a unique user name and password with which they can log on to the system. User selects the category of quiz to participate in.

Modules

DEMOS is mainly divided into four modules, namely

• User Management Module

• Question management module

• Quiz Execution Module

• Mark calculation module

User Management Module

The functions of this module are:

• Add new users to the user table.

• Authenticating users in the system.

We use user table for user authentication purpose and for storing user data.

Question Management Module

The functions of this module are:

• To add new subjects

• To delete the subject

• Add questions to each category of subject.

• Update questions

Here we use a single table for each subject .

Each subject has 10 questions and each question has 4 choices.

Quiz Execution Module

The functions of this module are:

• Quiz Selection

• Listing a single question and its choices at a time

• Verifying selected answer

• Displaying the mark

• Navigating to the next question

Mark calculation module

The functions of this module are:

• Calculation of marks for each of the participants.

• Toppers of each Subject are found

The marks are stored in Marks detail table.

The Toppers are stored in Subject Table

Android Application for Call Taxi

A

This project addresses the study of the recently launched Google Android platform, and its online application marketplace, called the “Android Market.” The project examines the paths to success for third-party developers building applications for Android by comparing them with application development for the Apple iPhone. In addition, the project also includes a study of the Android business ecosystem. Research on related topics shows that mobile ecosystem benefits third-party developers and those application vendors play a critical role in contributing to the success of Android.

The main goal of this project is to develop an accessible and comprehensive Eclipse structure application, can potentially assist individuals to book a taxi from a phone and for the company to maintain a database for booking and sending driver details.

Existing system as Call Taxi Wiki, which is a system exists in the market for one year, the existing system helps user to find the nearest taxi around in a particular city. The system all allows full internet access. However, the number of cities in the whole world is huge; database can’t store all the cities names.

Methodologies are the process of analyzing the principles or procedure of a progressive Call taxi system.

Main Module’s

Sign up

Driver And Customer login

New booking and cancel booking.

Confirm booking xi

Transaction Status

Sign up:

This is the first step what user to do. In this module, user wants to create an account in database, to call taxi from system. The registration processes are done by any person non-violating the database privacy rules. The registration will be permitted by call taxi system administrator. After the registration process completed user can get the authentication code and machine generated user id, by using this only user can login to the call system.

Driver and Customer Login:

In this module user want to register the personal details in the call taxi company database and get the authentication processes to go forward.

User booking and cancel booking:

In this module authorized drivers can book a taxi from the call taxi system. Here also shows all the details about the driver who also registered in the system. And the system admin give the personal details to the particular driver only after the matching process is done. Now the matching process is done by the admin. After getting the user details, driver can wait the user confirms the booking.

Confirm booking:

In this process, user will get the information about the distance, time and required fees from the system, then booking can be confirmed or cancelled in the above module.

Transaction status:

This is a module in which only admin can access, all registrations got permitted by this module. Booking request by users and drivers’ information also can be viewed in this module, such as the admin will arrange available driver to serve the particular request.

Application

Call Taxi System is used to maintain the user database in the format. It also very easy to retrieve the accurate data from a database, here all the information about the user are maintained securely and also here we achieve the confidentiality for the data’s stored in the database.

Concerning the actual execution of the database update, once the system has verified that the Booking be safely inserted to the database the data can be easily accessed and be used for further purposes and also the transactions can be done both the ways. Its applied by retrieving information from the database and storing through the android application.

Future Enhancements

Devising private update techniques to database systems that support notions of anonymity different than k-anonymity.

Dealing with the case of malicious parties by the introduction of an un-trusted, no colluding third party.

Implementing a real-world database system.

Improving the efficiency of an application, in terms of number of transactions exchanged and in terms of their sizes, as well.

Highlights of the Project

A system which can be used for user to login to connect a database is proposed. The user can just login to the system over internet, and book the taxi from location to location. With the help of the proposed system, user can book taxi without making phone call, which takes time to wait to call in. In the proposed system, checking the data that are entered in the databases does not violate privacy, and performs such verification without seeing any sensitive data of an individual.

Under this approach, the entire tuple has to be revealed to the party managing the database server, thus violating the privacy of the user. Another possibility would be to make available the entire database to the user so that the user can verify himself if the insertion of his/her data violates his/her own privacy. This approach however, requires making available the entire database to the user thus violating data confidentiality. Once this anonymized record is stored in the research database, the non anonymized version of the record is removed from the system of the facility. Thus, the research database used by the researchers is anonymous.

System Specification

The hardware and software requirements for the development phase of our project are:

Software Requirements :

• FRONT END : Eclipse with Android plug

• BACK END : MYSQL

Hardware Requirements :

PROCESSOR : PENTIUM IV 2.0 GHz, Intel Core 2 Duo.

RAM : 512 MB DD RAM

Phone : Android Phone

CDDRIVE : LG 52X

KEYBOARD : STANDARD 102 KEYS

MOUSE : 3 BUTTONS

Access My PC

Access My PC, as we call it, is a software that allows users to access devices connected to their systems from remote locations. The process starts when the different users, who need the facility, get registered through our website and download the application program for the said facility. Once the software is installed on the home pc then the user can access the devices connected to the system from any location using our website through the Internet.

A simple registration form is provided to the user wherein he can enter his name, address, contact number, email id, login id and password. After filling up the proper information, the user gets successfully registered for the application software. The user is authenticated for his login name and password, which was provided to him during the registration process. If the user fails to give his proper login id or password, an error message is displayed to him indicating that the login id does not exist.

The user has the option for downloading the software to the particular system that he is using. Once the system is installed in that system, say the Home PC, then the devices connected to that system can be accessed easily using our website.

Accessing the various devices connected to the Home PC is the feature that is being implemented in the project. Every user will have a particular Access code to be entered for getting access to this feature. If the Access code entered is wrong then the user get automatically logged out. Once the correct Access Code is entered the user can access the device he wants. The user can sign out of the login area any time using this function.

User Registration

A simple registration form is provided to the user wherein he can enter his name, address, contact number, email id, login id and password. After filling up the proper information, the user gets successfully registered for the application software.

Login and Authentication

The user is authenticated for his login name and password, which was provided to him during the registration process. If the user fails to give his proper login id or password, an error message is displayed to him indicating that the login id does not exist. If the login is successful then the user is able to perform the following functions:

• Software Download: The user has this option for downloading the software to the particular system that he is using. Once the system is installed in that system, say the Home PC, then the devices connected to that system can be accessed easily using our website.

• Access Devices: This is perhaps the purpose of Access My PC. Accessing the various devices connected to the Home PC is the feature that is being implemented here. Every user will have a particular Access code to be entered for getting access to this feature. If the Access code entered is wrong then the user get automatically logged out. Once the correct Access Code is entered the user can access the device he wants.

• Logout: The user can sign out of the login area any time using this function.

System Architecture

The System architecture has to be designed keeping all the above functions in mind. We can see that the system consists of mainly the following three parts:

Home PC

Home PC is the personal computer, which is owned by the user. The software that is Application part resides on this computer. It gets the data from the device and transmits it to the remote PC location and it also gives the status of the remote PC location. It has no level of user authentication. But it is the application part of this system that checks for the user device accessing. Home PC consists of mainly five modules namely:

• Network Interface: This is the part of the application, which is connected to the network.

• Data Manipulation Unit: This prepares the data from the devices to suitable for the network transmission.

• Device Access Module: This gets the data from the user from the interface corresponding to each of the users.

• Control Unit: Controls and coordinates each of the units in the Home PC.

• Device Interface: Interface of the operating system of the PC with the device so as to facilitate the communication between the two.

The Home PC consists of Data Manipulation and Device Access units. These two units are controlled by a Control unit. The Home PC is connected to a Network Interface. It is also connected with the devices via Device Interface.

System Requirement

After analyzing the requirements for our project we had come to the conclusion that our project users require the following requirements.

Client’s Requirements:

Needs a network connection

The account bound with a separate username and password for every user.

Needs the Internet facility

Server’s Requirements:

Should be connected to the Internet

Needs a Java Runtime Environment

Needs a database

System Specification

The hardware and software requirements for the development phase of our project are:

Software Requirements :

Development Tools : Java, JSP, HTML

Back end : SQL Server 2000

Browser : Mozilla 2.0 or IE

Web Server : Apache Tomcat Server

Hardware Requirements :

Processor : Pentium IV

RAM Capacity : 256 MB

Hard Disk Space : 40 GB

Mouse : MS Compatible

Keyboard : Standard 104 Keys

Monitor : Standard 15”

Floppy Disk Drive : 1.44 MB

Biometric Authentication System Using the Human Ear

Biometrics is the science of identifying or verifying the identity of a person based on physiological or behavioral characteristics. Biometrics identification methods have proved to be very efficient, more natural and easy for users than traditional methods of human identification. In today’s world security plays a very important role in organizations and particularly computer systems .

To make systems more reliable and secure, several biometric techniques that exploit physiological and behavioral traits and characteristics of people have been developed for verification and identification of the individuals. Biometric authentication systems are essentially pattern recognition systems, the physiological characteristics being fingerprint, face, hand geometry, DNA and iris recognition.

The main aim of the project is to develop a biometric authentication system using the ear. The process will involve several steps from acquisition of the image to the point where a positive identification can be made using the system. The image was acquired using a digital camera.

The photo is then processed, stored and used for the identification process. For every individual, there are some distinct features that can be used for identification. The portion or segment that contains these unique features is known as the Region of Interest. After the raw data is obtained, the Region of Interest (ROI) which is the area containing the ear image is chosen.

Feature extraction filters the uniqueness data out of the raw data and combines them into the biometric feature The method applied for this is Edge detection. For “easy” images from the database error-free recognition was obtained. When all the external conditions such as lighting are effectively controlled and remain constant, all the system produces a perfect performance with accurate results all the time.

The Ear as a Biometric

In proposing the ear as the basis for a new class of biometrics, there is the need to show that it is viable (i.e., Universal, unique, Permanent, Collectable). In the same way that no one can prove that fingerprints are unique, there is no absolute way to show that each human has a unique pair of ears. Instead, an assertion that this is probable can be made based on supporting evidence from two experiments conducted by Alfred Iannarelli (Appendix 2). It is obvious that the structure of the ear does not change radically over time. Medical literature reports that ear growth after the first four months of birth is proportional. It turns out that even though ear growth is proportional, gravity can cause the ear to undergo stretching in the vertical direction.

The effect of this stretching is most pronounced in the lobe of the ear, and measurements show that the change is non-linear. The rate of stretching is approximately five times greater than normal during the period from four months to the age of eight, after which it is constant until around 70 when it again increases. Since every individual has ears, it is rational to conclude that the ear is universal. The ear is also collectable using various means. The ear has several unique key points that can be used for identification. The major problem in ear identification systems is discovering an automated method to extract those specific key points.

Advantages of Using the Ear

The use of the ear has certain advantages. These include:

It is passive. Unlike the fingerprint and iris, it can be easily captured from a distance without a fully cooperative subject.

Unlike the face, the ear is a relatively stable structure that does not change much with the age and facial expressions. The shape does not change due to emotion as the face does, and the ear is relatively constant over most of a person’s life.

The ear’s smaller size and more uniform color are desirable traits for pattern recognition. The uniform distribution of color means that almost all information is conserved when converting the original image into gray scales.

Application Scenarios

Basically there are two types of application scenarios:

Identification (also known as recognition)

Authentication (also known as verification) Identification (“one-to-many matching”) implies matching a biometric sample against all records in a database of templates.

The individual presents a biometric sample and the system tries to identify the individual from a database of stored biometric samples. This process intends to answer the question “Who is he?” Biometric verification requires comparing an enrolled biometric sample (biometric template) against a newly presented one. It is a “one-to-one matching” process.

In authentication the comparison is done only with data, which is known to be valid for the approved person, e.g. the fingerprint or hand shape is included in an identification card. The card will be entered first to the system. After that the system verifies that the new biometric is valid with the one which was in the identification card. Ear biometrics can be used as a supplementary source of evidence in identification and recognition systems

Highlights of the Project

This project was aimed at developing a biometric authentication system based on human ear images. An invariant geometrical method was used in order to extract features needed for classification. After the feature extraction, authentication is performed based on simple comparison between a new input image and an already existing one. The human ear is a perfect source of data for passive person authentication in many applications. In a growing need for security in various public places, ear biometrics seem to be a good solution, since ears are visible and its images can be easily taken, even without the knowledge of the examined person. Then the robust feature extraction method can be used to determine personality of some individuals, for instance terrorists at the airports and stations.

Access control to various buildings and crowd surveillance are among other possible applications. Ear biometrics can be also used to enhance effectiveness of other well-known biometrics, by its implementation in multimodal systems. Since most of the methods have some drawbacks, recently, the idea of building multimodal (hybrid) biometrics systems is gaining lot of attention. Due to its advantages, ear biometrics seems to be a good choice to support well known methods like voice, hand or face identification.

System Specification

The hardware and software requirements for the development phase of our project are:

Software Requirements :

OPERATING SYSTEM: Windows XP or Windows Vista

DEVELOPMENT KIT : MATLAB

Hardware Requirements :

Image Acquisition Device: CCTV or Digital Camera

Processor : Pentium IV or higher

Hard Disk : 40GB or more

RAM : 256MB or more

Congestion Control in ATM-based Broadband ISDNs

In this paper, a new congestion control technique for ATM networks is presented. The technique includes admission control, and traffic shaping. The network traffic consists of real-time traffic and data traffic. Call acceptance is based upon the effective bandwidth and data traffic flow is controlled by effective buffer.

Effective bandwidth for a switching node is defined as a vector of bandwidth and an estimated maximum delay at the node. Effective buffer is defined as a scalar of buffer size. The proposed scheme is analyzed by simulation and the results are presented in comparison with other studies under similar traffic conditions.

Proposed Technique

The proposed congestion control technique features parameterized call acceptance. Available bandwidth and maximum node delay are two crucial parameters used for setting up connections. Bandwidth is pre-allocated for real-time traffic based on prescribed mean bit rates. Available buffers are the control parameter for admitting non-real-time cell transfers on a link-by-link basis. Details are shown below [4].

1. Two types of traffic are defined in the model: a) Real-time Traffic (RT): Cells of this type are delay-sensitive. They must be delivered to the destination within a predefined time frame. b) Data Traffic (DT): Cells of this type are delay-insensitive, but they are loss-sensitive. All cells must be delivered.

2. EB ( E ffective B andwidth) is the criterion used for call acceptance. There exists a separate EB for each type of traffic and for each node. EB is a two-element vector with the format of EB = (x, y).

The EB of a node is defined as follows:

EB i = (C AVAIL i , M i ) (1)

Where EB i = the EB of node i

C AVAIL i = the available (unallocated) channel capacity at node i

M i = the maximum node delay at node i

Note: For simplicity, all definitions in this model are time-implicit. The time factor is syntactically omitted but intuitively understood. For example, EB i is short for EB i ( t ), denoting the EB of node i at time t (the time node i is inquired).

The EB of a RT traffic is defined as:

EB RT i,j = (B RT i , D RT i,j ) (2)

Where

EB RT i,j = the EB of the i th RT traffic at node j

B RT i = the prespecified mean bit rate of the i th RT traffic

D RT i,j = the allowable maximum node delay of the i th RT traffic at node j , and

D RT i,j = D RT i,pred(i,j) - M pred(i,j)

Where

pred(i,j) = the predecesor of the j th node of the i th traffic

The EB of a DT traffic is defined as:

EB DT i,j = (0 DT i , D + DT i,j ) (3)

Where

EB DT i,j = the EB of the i th DT traffic at node j

0 DT i = the prescribed mean bit rate of the i th RT traffic is zero (at the connection

setup time)

D + DT i,j = a quantity that is larger than the allowable maximum node delay for the

i th RT traffic at node j

EB 1 = ( x 1 , y 1 ) and EB 2 = ( x 2 , y 2 )

A RT connection request is granted only if its EB can be satisfied by all intermediate nodes on the route; i.e., RT i can be granted its connection request only if O(EB j , EB RT i,j ) = 1 is true for all j 's on the routes. A DT traffic is also connection-oriented. However, a DT connection request is always granted. From the EB definition for DT traffic (Definition 3) we know that acceptance is instantaneous.

In this case, a route can be selected randomly by the entrance node. EF ( EF ective buffers) is the major criterion used to grant cell transfer requests for DT traffic from node to node. There exists a separate EF for each DT cell transfer request and for each node. EF is a scalar quantity.

The performance of the proposed congestion control technique is evaluated by using simulations. We assume the following for all our simulations: a) Channel capacity allocation is based on the prescribed mean arrival rate for each input source. b) RT traffic is shaped by employing a leaky bucket method [5] based on the channel capacity allocated.

In our simulations, the leaking rate of a leaky bucket queue coincides with the service rate for that queue. c) Each DT input source is allocated a large buffer (a fat bucket policy) to accommodate sudden bursts of cells without risking any loss. d) The system is in equilibrium and running at full speed (all channel capacity allocated) when it is analyzed

 

Mobile Recharging With Banking Transaction Using SMS

 

The main aim of this project is to provide a customer Friendly service of getting the card recharged and enable the Banking transaction activity by activating transfer of account through SMS. It serves as a helping hand to the people by rendering the service availed to the customer at its level best by skipping traditional customs of on person availability in Banks & other sectors

1. Mobile Recharge

2. Transaction on mobile

 

Mobile Recharge:

The SMS must include the details regarding the account number , PIN number and amount for recharging , after this SMS is sent and it passes through mobile receiver where it is checked for validation. After the bank server approves the transaction of deduction in the amount in the bank amount. The request is directed to the mobile server.The mobile server acts after receiving the intimation from the bank server and successfully recharges the card there by sending the reply from bank to mobile user.

 

Transaction on Mobile:

Transaction on mobile is used to money between two peoples. These two peoples must be registered in a bank. And they should have mobile transaction. This transaction starts with SMS. If user 1 wants to pay Rs.3000 to User 2 .user 1 simply type SMS to particular bank with his 4 Digit PIN, Amount and Account No. the request is processed by the bank server and Amount is transferred to designation account.

In order to improve the available facility, we are developing software for both mobile recharging and bank transaction using mobile SMS as wireless communication. SMS appeared on the wireless scene in 1991in Europe, where digital wireless technology first took root. The European standard for digital wireless now known as the Global Standard for Mobile (GSM) included short message services from the outset. A distinguish characteristics of the service is that an active mobile handset is able to receive or submit a short message at any time independent of weather or not a voice data call process. SMS is characterized by out-of-band packet delivery and low bandwidth message transfer. The benefits of SMS to subscriber center around convenience, flexibility and seamless integration of message services and data access. Short message service center is responsible for the relaying and store and forwarding of short message between mobile and mobile station

Methodology

This project work on the basis of Wireless Application Protocol (WAP). WAP is the next generation of new communication transaction. It is an open specification That offers a standard method to access Internet based content and services from wireless ices such as mobile phones. Wireless mobile kit to send and receive the messages. Mobile receiver acts as a interface between mobile kit and other servers. Database maintenance and administration. Rendering service to the customer an tool kit empowered with Java 2 Micro Edition to represent the model of the process of inflow and outflow of messages. Link must be maintained between mobile kit and servers to hold sway the message and transferring it swiftly to the respective servers by means of filtering. This is done bye mobile receiver.

An process of keeping the personal details and process of transaction of account holders are maintain in a database .It also administers the process of authentication and validation of banking transaction there by updating the relevant information and by executing the task. Mobile server is the key for offering and effecting the service to the customer. It is natural for it has a database containing the detail of recharge (last date and balance amount of account). A tabled of data for individual customer is also maintained to envisage the query service.

Recharging the Mobile

Step 1: Activation the mobile server, bank server and mobile receiver is done.

Step 2: Once these are activated, get the account number, PIN number and the amount to be recharged.

Step 3: The recharge request is sent to the mobile receiver. The request contains information such as account number, PIN number, and amount.

Step 4: The mobile receiver sends the request to bank server for verifying the account number, PIN number and the amount to be recharged.

Step 5: If the information is true then the values in the bank server and mobile sever is updated accordingly.

Step 6: Otherwise, it sends an error message to mobile kit.

Step 7: Terminate the process.

Bank Transaction:

Step 1: Activation the mobile server, bank server and mobile receiver is done.

Step 2: Once these are activated, get the source account number, destination account number, PIN number and the amount to be transferred.

Step 3: The transaction request is sent to the mobile receiver. The request contains information such as source account number, destination account number, PIN number, amount.

Step 4: The mobile receiver sends the request to bank server for verifying the account number, PIN number and the amount to be transferred.

Step 5: If the required amount to be transferred is available in the source account, the bank sever is updated with that in the destination account.

Step 6: If the required amount is not available then it sends the error message to the mobile receiver from which it is displayed in the mobile kit.

Step 7: Terminate the process.

Future Enchancements

To foresee the balance amount in the bank.

It can be implemented to have credit & debit based transaction.

Footing the bill for electricity, telephone, taxes that will be deduced at banks by means of SMS.

Providing valuable information to the customer about the new arrival of schemes in the company and offers rendered by the company.

Reserving tickets in modes of transport & booking made in the theatres via SMS.

Reporting the stock values, hot news and sending remainders.

Applications:

It can be applied for using the major cellular operations to provide userfriendly services.

It offers valuable services in the area where the operators are out of reach.

There is no geographical bar on its usage.

It can be accessed at “any where at any time” money transfer & mobile recharge.

Highlights of the Project

Through the Internet transaction facilities are improved the mobile transaction. It is restricted statically any specific area. The project has completed successfully and the result is verified with various inputs under various circumstances. The goal of our project is reached i.e., recharging the mobile and bank transaction through SMS. Thus the facilities on the mobile phone would makes transactions easy, time saving.

System Specification

The hardware and software requirements for the development phase of our project are:

Software Requirements :

Platform : Windows 98/2000/NT

Front End : Java JDK1.3, Java Applets, Tom cat 1.4

Tool : J2ME Wireless Tool Kit 1.0.4

Back End : Microsoft Access

 

Hardware Requirements :

Processor : Pentium IV 2.5 Ghz

RAM : 256 MB

HDD : 40 GB

FDD : 1.44 MB

Keyboard : 105 Keys

Monitor : 14” Soft White color SVG