1. Chatter Box Daniel Dunham Nick Noack Mike Nelson

2. Overview Project description Usage scenario Project components Important issues Division of labor Schedule and milestones

3. Project Concept Interfaces to the personal server ‘Standard’ Visual display with keyboard/keypad Alternative Audio based I/O via cell phone

4. Why Use Audio? Speech is an easy, natural way for people to receive and provide input Cell phones are commonplace Cell phones already being built with Bluetooth capability

5. Project Goals Simulate a cell phone for audio recording and transmission Develop the personal server audio interface Develop an application to exhibit the audio capabilities

6. Cell Phone Simulator Ideal project would use a real cell phone Cell phone software is proprietary Hence, prototype using a tablet with microphone, speakers, number pad

7. Audio Development Audio support will be developed incrementally Along the way some basic useful applications are realized

8. Audio: First Step Transmission to and storage of audio data on the personal server Application: memo device User records notes (speaking into phone) At a later time user listens to notes – meetings, thoughts, etc

9. Audio: Second Step Text-to-speech support Important aspect of an audio interface Application: book reader Take a book in text format and read to the user with a synthesized voice

10. Audio: Final Step Text-to-speech is one direction of the I/O Other direction: speech-to-text More difficult than text-to-speech Settle initially for speech-command recognition

11. Application for the Audio Numerous potential applications, as seen already Our personal favorite: provide people with a tool to view dining options

12. Restaurant Selector Restaurants broadcast menus over short-range radio link Personal server receives menus, adding them to a database of menus If the person is hungry, they access their personal server (via PDA, kiosk, phone, etc)

13. A Sea of Options Application helps to narrow them down

14. Restaurant Selector Features User can input dietary preferences/restrictions to narrow down the options they will be shown On a diet? Specify caloric limit, cholesterol limit, etc Restaurant selector only shows you what you can (or should) eat Remove temptations before you see them

15. Restaurant Selector Features User specifies with spoken commands what he wants “Find Italian please” “Price limit seven dollars por favor” Speech recognition matches request to a set of commands and displays restaurants meeting the specifications May require training

16. Restaurant Selector Features Add-on: GPS Allows added search constraint based on distance of user from restaurant If we get bored, add some navigational assistance

17. Usage Scenario Joe the hip, happening college student Owns a personal server (naturally) Goes to the Ave looking for food Dials up his personal server Brings up a list of Thai restaurants Joe’s allergic to peanuts His personal server knows this Later in Sieg, Joe’s friends are hungry too

18. Important Issues Text-to-speech and speech-to-text still an untested black box Restaurant search options: how much do we allow/require from restaurants Example: Will restaurants have precise nutritional information? Key: Allow easy change

19. Project Summary Audio interface Text-to-speech, command recognition Restaurant selector Dietary preference specification Constrained searching Project components Hardware, audio, restaurant app

20. Project Summary Major issues Speech-to-text Restaurant filtering specifics Division of labor Audio: primarily Nick Restaurant filtering app: primarily Mike Hardware: primarily Daniel