1. Vending Machine Through Mobile (A BLUE TOOTH BASED APPLICATION)

2. GOAL OF OUR SYSTEM User can use a cell phone to select the product to be purchased from among a list of products and buy them through telemetry. OUR SYSTEM is J2ME based Bluetooth mobile application which when installed in a Java enabled mobile phone lets a user make a purchase of an item through the mobile phone.

3. Problems with the current scenario: Coin acceptors often jam up, especially if a bill or other foreign object is inserted into the coin slot. Moreover these vending machines are not smart enough to give you change for the products you have bought. Also these vending machines need more manual interaction which is not always recommended. Also people are looking for innovative solutions from the vendors to their buying problems.

4. PLANNING

5. Proposed Solution The scheme relies on a radio frequency transmission medium, which guarantees fully bi-directional This scheme has opened door for the vendors to adopt a new alternative paying scheme that will help them to attract the customers. This project also focuses on developing an alternative scheme for payment through credit cards.

6. MODULES There are four modules present in the system. They are: Vending Machine Module Purchase Request Module Billing Module Payment module –Talk time. –Credit card Payment

7. Vending Machine Module Functionality: Show List The lists of the categories available in the repository The products in the selected category are also displayed. Update Inventory Whenever products are purchased, the amount of products sold will be deducted from the inventory levels. When the inventory level of a product goes down the minimum requirement, product name will be deleted from the available list of products. It has to be updated again by the administrator whenever the product is added to the inventory.

8. Purchase Request Module Functionality: Viewing the list of categories of products. To make a request for buying a product of desired quantity.

9. Billing Module Make Bill A bill is generated for the purchased product. Transaction Log Records the list of transactions performed

10. Payment module Credit card Payment If the payment is through the credit card, then the card details will be send to the bank and the amount will be collected later. Talk time payment If the payment is through service provider then the amount of purchase will be deducted from the user’s talk time.

11. SOFTWARE REQUIREMENTS SERVER Operating system ---- Windows XP Server Side Prog ---- java Servlets Web server ---- Apache tomcat 5.5 Database ---- Oracle 8.0 Client Operating system ---- Palm OS Blue Tooth Mobile ---- J2ME Wireless Toolkit

12. HARDWARE REQUIREMENTS Server PIII or higher processors 256 MB RAM 20 GB Hard Disk Client Bluetooth enabled mobile phone is sufficient

13. ANALYSIS

14. FUNCTIONAL REQUIREMENTS

15. The actors identified in this system are: User. vending machine. Service Provider TTP

16. The use cases that are identified in this system are 1. View repository 2. Select category 3. Select product. 4. Billing system 5. Sim card payment. 6. Credit card payment

17. MAIN USE CASE DIAGRAM

18. SUB USE-CASE FOR PURCHASE

19. SUB USE-CASE FOR VIEW REPOSITORY

20. ACTIVITY DIAGRAMS Activity diagrams are special case of the state machine Activity diagrams provide a view of flows of what is going inside the use cases or among several classes

21. Activity diagram

22. SEQUENCE DIAGRAMS Provides graphical view that shows object interaction in time based sequence These diagrams establishes the roles of the objects and provide essential information to determine class responsibilities

23. UPDATE INVENTORY

24. PURCHASE

25. CREDIT CARD

26. SIM CARD

27. CLASS DIAGRAM Class diagrams are created to provide a picture or view of some or all of the classes in the model. The main class diagram in the logical view of the model is typically a picture of the packages in the system

28. CLASS DIAGRAM

29. FUNCTIONAL ARCHITECTURE

30. Mobile with vending machine

31. Vending machine checks database

32. Checks bank details

33. Checks service provider

34. SYSTEM ARCHITECTURE

35. BALANCE CNAME PNAME BILLING SYSTEM TID TMOD E BAMOUNT TDATE PNAM E CREDITCARD CVVNO CName CARDNO CARD TYPE EXPIRY DATE SERVICE PROVIDER To MNAME SIMN O PIN ACTI CTYPE MNAM E INTER ACTS PRODUC T COST BUYS Vie ws CATEGRO Y INTER ACTS

36. List of data base tables identified Category Products Measurement Transaction Service provider Visa Transaction processing(ttp) vodaphone

37. cnameVarchar2(20)primarykey pnameVarchar2(20)primarykey cnameVarchar2(20)Foreign key Product table Category table Cname represents customer name Pname represents product name

39. Measurement table pnameVarchar2(20)Foreign key mnameVarchar2(20)Primary key quantityNumber(3)Not null costNumber(7,2)Not null

40. Transaction table TidNumber(5)Primary key TmodeChar(1)not NULL BAmountNumber(7,2)not NULL TdateDatenot NULL PnameVarchar2(20)Foreign key MnameVarchar2(10)Foreign key

41. Service provider NameVarchar2(20)Primary key

42. Vodaphone CnameVarchar2(20)Foreign key Sim noNumber(10)Primary key PinNumber(6) Not null BalanceNumber(6,2)Not null activationChar(2)Not null

43. TRANSACTION PROCESSING NAMEVARCHAR2(20)PRIMARY KEY

44. VISA CNAMEVARCHAR2(20)FOREIGN KEY CARDNONUMBER(16)PRIMARY KEY EXPIRY DATE DATEnot NULL CREDIT CARD NUMBER(7,2)not NULL CVV NONUMBER(10)not NULL

45. Interface design

46. Welcome screen

47. categories

48. List of products

49. Puchase the products

50. Pay mode

51. Account details by sim card

52. Account details by using credit card

53. Receipt form

54. TESTING

55. Authentication of user with Service Provider Test Case: Authentication of user Test Description: With the cell phone number and pin as the input, validate the user. Pre Conditions: User should have a Valid Account with Service Provider Action Performed: 1) Correct details entered. 2) Wrong details entered. Expected Results: 1) Connected to server and product is delivered. 2) Not Connected to server and Repurchase. Conditions Verified: yes Result: Success

56. Product Available Test Case: Product Available Test Description: To verify the Product of Sufficient quantity is available Pre Conditions: Database Connectivity Action Performed: 1) Product Available. 2) Product Not Available Expected Results: 1) Ask for Payment Details. 2) Alert the User. Conditions Verified: yes Result: Success

57. User Validation Test Case: User Validation Test Description: With the credit card and cvv no. as the input, validate the user. Pre Conditions: User should have a Valid Account with bank. Action Performed: 1) Correct details entered. 2) Wrong details entered. Expected Results: 1) Connected to server and product is delivered. 2) Not Connected to server and Repurchase. Conditions Verified: yes Result: Success

58. CONCLUSION The following benefits can be observed with this system: Convenience and flexibility in the mobile payment scheme. A reliable scheme with completely no manual interaction. Also the reports generated by the system can be helpful in tracking the customer needs and maintaining the correct inventory levels. Moreover by implementing this system we gained a clear understanding of project life cycle and the Bluetooth technology.

59. LIMITATIONS This project of course has a broad range but was implemented only for the vending machine scenario. Also this project, as it is implemented using Bluetooth technology, was constrained to the distance of operation.

60. FUTURE ENHANCEMENTS This project can further be extended to a wide range of products and categories. An example of the future enhancement is an ATM machine where a user can make a transaction through any bank card at a single place. Implementation of project in Real Time Environment Also it is possible to bring a variety of customers under one roof with the help of this system.

61. ThanQ