Patent Application
20110112992
A large part of energy consumption lies in transportation. People commute to work, run errands, visiting family, etc. This consumes large amounts of energy in the form of fuel to operate the mode of transportation and consume large amounts of time as people move from one area to another. A capability of combining errands in a convenient and location-oriented way would be helpful to users and would conserve resources.
Some research has occurred in areas related to this type of capability including activity recognition, rhythm modeling, prediction of user transportation destinations, prediction of future locations, and using GPS (global positioning satellites) to learn significant locations for users.
Examples of activity recognition have been published as US Patent Publications. In one example, published as US Publication No. 20090073033, a system infers user activities based upon a trace of the user's location and a mapping of that location to a venue, such as a restaurant. A user's query is then received and given the context inferred from the user's location the system may provide a recommendation as to activities that can better match the user's preferences.
Other work related to people's movement and patterns involves “rhythm modeling” or methods of detecting and modeling a person's movements and activities using a database of online presence data. An example of such work is found in “Rhythm Modeling, Visualizations and Applications,” by Begole, et. al., Proceedings of the 16th Annual ACM Symposium on User Interface Software and Technology, pp. 11-20, 2003.
Part of rhythm modeling involves predicting where a person will be or when the person will be at a particular locale. Other work in prediction of people's movements includes predicting a driver's route for location-based services by John Krumm and Eric Horvitz, “Predestination: Where Do You Want to Go Today?” IEEE Computer Magazine, vol. 40, no. 4, April 207, pp. 105-107.
Prediction of short-term activity patterns, such as daily activity patterns is discussed in “Predicting Future Locations Using Prediction-by-Partial-Match,” by Ingrid Burbey and Thomas Martin, Proceedings of the First ACM International Workshop on Mobile Entity Localization and Tracking in GPS-less Environments, pp. 1-6, 2008. Another example of such predictions, based upon GPS locations, can be found in, “Using GPS to Learn Significant Locations and Predict Movement Across Multiple Users,” Personal and Ubiquitous Computing, pp. 275-286, 2003.
Most of the location prediction work focuses on short-term prediction within minutes, hours or a day. Very little work exists on longer time horizons. In addition, much of the existing work is about predicting activities and locations, but not on opportunistic or energy-saving recommendations.
It is possible for a tasking system, upon implementation of the embodiments here, to determine situational data, such as the user's location, using a Global Positioning Satellite (GPS) transponder is in the user's device. The system could then access tasking data, such as a calendar, to-do list, emails from particular people, etc., and determines that the user needs to pick up dinner, get a book for his daughter and go grocery shopping.
Using the situational data and the user's preference to save time, the device could make a recommendation that the user order dinner to go, and then drive to the strip mall, get the book, go grocery shopping and then pick up dinner and go home. If the user's preference is to save driving, the system may alter the order of recommendations to have the user start closer with dinner pick up and then recommend the trip to the book store and the grocery store on the way home. Either of these recommendations would save the user an extra trip, as may happen because the user forgot about the book and gets home only to have to go back out again, as well as taking the opportunity of the user's location to allow the user to consolidate errands, etc. saving time and fuel.
Other components of the system, such as the tasking repository, or the processor that does most of the work may reside at the server, on the user's device, or shared between the two. For example, the tasking data may reside in the server, but the memory on the device may also be checked for any entries made by the user that have not been synchronized to the server yet. Similarly, the processing of the data may be shared between the two devices, with the server performing the bulk of the processing prior to producing the recommendation and the user's device doing the presenting of the recommendation to the user.
Components of the system will be discussed with regard to
The mobile device 12 may have several sensors, where the term sensor is broadly defined. This may include a wireless radio interface 21, such as a Wireless Fidelity (Wi-Fi) radio interface, or a cellular network radio interface as examples that detect the presence of a network and interface with the radio 24 and/or the network interface 22. The sensors may include a voice sensor or microphone 40 as well as light, temperature and other types of sensors.
An additional sensor may be an accelerometer such as 30 that detects the orientation of the device. Note that as used here, a device's orientation differs from its location. The orientation sensor, such as accelerometer 30, detects the orientation of the device such as in vertical or horizontal mode, while the location sensor, such as a GPS locator 28, detects the device's location on a grid or region. Using the network or radio interface, or a combination thereof, such as using the radio to access the Internet, the device could access several resources to assist with locating venues around the user that provide opportunities for task fulfillment, such as the grocery store discussed above. Alternatively, the network or radio interface may connect the device with the server 13 through the server's network interface 42, those resources residing on the server or the server handling the interfaces with those resources, as well as the detection of the device's position and orientation. The environment module 29 that performs these operations could reside on the user's device, on the server or be distributed between the two.
The processor 26 may determine the tasks to be fulfilled by accessing a repository 32 of data. Many systems employ calendar and task software such as Microsoft® Outlook® as an example. In addition, the system may also store emails 36 that can be parsed and analyzed to identify requests or to-do items sent from other people. This would provide the system with task to-do lists 34 and appointment data from the calendar 36. Further, the system may also track activities of the user.
Activity tracking may involve pattern identification, where the system would gather data related to the user's activities and then recognizing a pattern. For example, maybe the user spends an hour at a location every Saturday that corresponds with a grocery store. When the user is in a location near the grocery store on a Saturday, the system would use the activity data to provide a recommendation that the user go grocery shopping. The activity data plus any other data such as task to-do lists, calendar data, emails, etc., will be included in tasking data for purposes of the discussion here.
It must be noted that the device of
In operation, the system may analyze the tasking data to build a list of tasks to be fulfilled and then monitor the situational data to seek opportunities for fulfilling those tasks. Alternatively, the system may determine the situation first and then analyze the tasking data to determine if the situation provides an opportunity. In the discussions of
At 52, the system accesses the repository of tasking data. As mentioned above, the system may have already analyzed the tasking data and developed a prioritized task list, or it may analyze the tasking data on the fly and determined a set of tasks that may be fulfilled based upon the situational data. The actual implementation is left up to the designer, as the processing capabilities, the type and format of tasking data, etc., may vary from system to system and what devices are included in the system.
Accessing the repository of tasking data may include accessing priority parameters given by the user at 54. The user would typically interact with the system through a user interface on a mobile device such as a combination of a display and a set of controls or a touch-screen, such as 20 from
When the user initially employs the capabilities provided by embodiments here, the user may provide inputs as to the priority with which tasks are to be sorted at 54. Examples include saving time, saving energy, a maximum number of tasks to be fulfilled in one outing, etc. In addition, the user may provide inputs as to times or situations during which recommendations should not be provided, such as within a half hour of having to be at an appointment, or when the user is at a movie or in church, etc. These inputs are referred to here as priority parameters.
The system gathers all of this data and then determines if there is an opportunity to fulfill a task at 56. This process may involve the system parsing through all of the tasking data and looking for keywords and then comparing the user's location and nearby resources and venues to match the keywords with them. If the system determines an opportunity exists, it may provide notification to the user immediately. Alternatively, the user may have set parameters or the system may determine that notification should not occur. This may be based upon the system recognizing that the user is attending a movie, is driving, is at an appointment, in church, or the time is within a particular window of an event for which the user set that the user did not want to be notified. If no parameter is set that limits notification, or if notification is allowed at 58, the system would make a recommendation at 60.
If the system determines that notification should not occur during that period of time, the system may wait at 62 until the time period expires, or the user moves outside a particular venue such as a movie theater or a church, etc. The system may then determine if the recommendation is still valid at 64. Possibly the task to be fulfilled may be time-dependent, such as when a particular store is open, etc. If the recommendation is still valid at 64, when the notification window opens up, the system would then make a recommendation at 60 through the user's mobile device.
Once the recommendation is provided at 60, the system would then determine if the user completed the task. This may be done explicitly, such as following up with directly with the user through the user interface. For the example, the mobile device may inquire of the user whether or not the user completed the task, or may leave a message on the user interface that is cleared when the task is complete. Alternatively, the device may work implicitly to mark a task as completed. If the device makes a recommendation that the user go grocery shopping, and the user's location changes to a location corresponding to a local Whole Foods™ store for a half hour, the system may implicitly determine that the task of grocery shopping is complete.
However it determines completion of the task at 66, if the system does makes that determination it would update the repository of tasking data to show the task as complete at 68. If the user does not complete the task, the process would return to the system monitoring the situational data to look for another opportunity to complete that or other tasks at 50.
Having this capability provides the user opportunities to conserve resources, such as fuel, energy, time, etc., for that individual. This capability may also be employed across groups of people to allow users to cooperatively exchange errands, etc. across a group.
In
Once joined to a group, the user could enter requests such as someone picking up items for that person at a home improvement supply store. The user may also make offers, such as ‘I am going to the grocery store tonight, does anyone need anything?’ The user may make arrangements with the store for the items to be pre-stacked and package so that the task fulfiller who picks up the items will not know what is in the package. The user's request may be ‘picked up’ by a person who indicates that person will fulfill the task, for example user 76. If user 76 does not fulfill the task for whatever reason, the user 76 may ‘drop’ the task back onto the list.
The example shown in
Regardless of the overall system implementation, task fulfillment would typically operate very similarly to that of individual users.
The determination of an opportunity at 88 and the notification decision at 90 operate much as discussed at
The mechanism used to track the task fulfillment across the group may then notify the requester at 102. Again, this may result from a more formalized approach. In a more informal system the user that fulfilled the task may notify the requester with a phone call. As mentioned above, having a central point at which the task request and fulfillment data is tracked at 104, even if is it just one user's phone within the group, may allow the users to monitor usage for equity. Other user's may decide, on a peer level, not fulfill any more tasks for a user that has had several tasks fulfilled but does not fulfill any tasks. Alternatively, a more formal system may prevent or allow users to requests tasks based upon a credit system in which credits are earned for fulfilling tasks and are ‘spent’ for requesting tasks.
Other modifications and variations are of course possible. For example, the individual user recommendations may not always revolve around work or family related tasks such as groceries, etc. The tasking data may include information about activity levels and make recommendations with regard to leisure activities like going to a park, seeing a show, going bowling, etc. While those events and preferences may be referred to as ‘tasks’ they may not be tasks in the traditional sense of the word. One could imagine a user planning a vacation and making a list of attractions or sites to see or activities to do and the device providing recommendations based upon where the user is during vacation. If the user wanted to dive a coral reef while on vacation and the device may make a recommendation when the user is in a region that has several dive shops at some point in the vacation.
One of the advantages of such a system and its operation is the ability to use and make recommendations on data that relate across a longer time horizon than one day. Referring back to the example of grocery shopping, that recommendation is based upon a past pattern plus recognition of a weekly, not a daily, habit of the user.
It will be appreciated that several of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Also that various presently unforeseen or unanticipated alternatives, modifications, variations, or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.
