1 / 26

Context Aware Mobile Commerce

Context Aware Mobile Commerce. For CSE 535 Mobile Computing Phase III Colin Juillard , Duo Li, Joseph Caglio , Sayan Cole. Road Map. Goal/Motivation General approach Accelerometer context collection and analysis. Accessibility function implementation. Goal & Motivation.

jon
Download Presentation

Context Aware Mobile Commerce

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Context AwareMobile Commerce For CSE 535 Mobile Computing Phase III Colin Juillard, Duo Li, Joseph Caglio, Sayan Cole

  2. Road Map • Goal/Motivation • General approach • Accelerometer context collection and analysis. • Accessibility function implementation.

  3. Goal & Motivation • Add context to Mobile Commerce, and provide a whole new approach to plan activities. • Late to meetings, appointments, reservations. • Plan ahead of time. • Take interruptions into consideration and provide automatic update to events. • Efficiency for both users and clients in terms of time and resources. • Easy to use and easy to adapt to. Application learns from user, unlike the other way around.

  4. Location Aware Where the user is

  5. Location awareness • Mobile phones have the necessary hardware to support context awareness. • Context awareness can be used to provide relevant information to a user based on his/her location. • GPS can be used but has limitations • Consumes a lot of power vis-à-vis Wi-Fi. • Does not work indoors.

  6. Wi-Fi for context information • Wi-Fi hotspots becoming ubiquitous. • Hotspot broadcasts the SSID’s which give a hint as to the nature of service it provides. • Configure the Wi-Fi scanning process to search for specific SSID names. E.g. Starbucks if you want coffee

  7. Challenges • SSID name might not be unique or provide good representation. • Use IP address matching, as IP address of router is unique. • Wi-Fi scans consume more energy than average power consumed by GPS . Hence determination of scan interval extremely important for energy efficiency. • Scan only when required. Use accelerometer readings to set scan interval. (based on user movement)

  8. Wi-Fi vs. GPS power consumption • Used free software PowerTutor to measure energy consumption. • Using 10s scan interval, the power consumed by Wi-Fi for scan was 800 mW and average power consumption was 10 mW. (800*6 + 54*10 = 5.3 joules) • Using GPS, power consumed was 450 mW . (450 * 60 = 27 joules)

  9. Accelerometer Detecting what user is doing

  10. Why Accelerometer? • Measure and monitor user motion • Estimate time of arrival • Save energy • More activity – scan interval decreases • Less activity – scan interval increases • Provide interval decision for Wi-Fi scanning • Dynamic scanning provides accurate data while consume less energy

  11. Data Collection • Using Android API to collect accelerometer accelerations. • Acceleration in terms of X, Y, Z acceleration, then take the difference in magnitude divide by time between each sample. • Find the “cutting value” to distinguish various activity by accumulating number of actions detected over the “cutting value”.

  12. Data Analysis

  13. Overall • Using difference in Magnitude of Acceleration over time, we’re able to find cutting values for determining user motion. • Drawback • Prediction is only as accurate as the sensor. • Takes 20 seconds to collect 40 samples. • Future Work • Varying “cutting value” to improve accuracy. • Using Bluetooth accelerometer with smartphone.

  14. Accessibility Help user to do what they want to do

  15. Accessibility • Goal: Make our application accessible to visually impaired users. • Features: • Text-to-Speech: Give directions and information to the user on how to interact with the application. • Advanced User Mode: Once users have learned the interface, many of the directions do not need to be given again. • Speech recognition: Get user input and commands.

  16. Text-to-Speech • Requirements: • Android v1.6 (API Level 4) • TTS resources (must check to ensure language-specific resource files available) • Text-to-Speech usage • Install any required resource files • Initialize the engine • Convey instructions and information to the user by manipulating the TTS engine’s queue of commands • Add, Flush, Silence

  17. Advanced User Mode • Goal: Make our application useable on the go, which means less distracting. • Visually impaired users sometimes learn programs offline before using them on the go • Once learned, there is no need to repeat instructions • Advanced user mode speaks only required information

  18. Speech Recognition • Speech Recognition Usage • When button pressed (camera button used), start speech recognition activity. • Use results to change the state of the program. • Potential to speed up the process by creating shortcut commands • Problems Encountered • Slow to initialize the first time • Could not detect when the activity had started without being able to see it • Future Work • Use with newer phones. Android API Level 8 has new functions available for creating your own SpeechRecognizer instances.

  19. User Modeling Predicting what the user is going to do

  20. Different Ways of Doing It • Machine Learning • Complex (e.g. Gradient Decent requires differential) • Large Dataset (e.g. Netflix has millions of dataset • Simple Statistics • Simple (e.g. Average requires summation and division) • Can Have Small Dataset

  21. Our Solution (Simple Statistic) • Histogram Based on Time • High Occurrence Can Easily Be Seen • Can Add Complexity

  22. Implementation More details on how we implement it on our application

  23. What We Did • Each Day is a Separate Histogram • Each Histogram is Divided into 5 Minute Increments • Each Time User Use Application, Mark it on Corresponding Day and Time • Look at Next Day Histogram at 8:00pm Each Day • Group Neighbors Together (can have 1 or 2 gaps) and Set Notifications

  24. Results… TBA • Results for this requires extensive testing • Multiple Users is Needed to Get Accurate Measurements • Can Have Study of Different Users to See the Average Usage Base on Type of User

  25. Questions?

More Related