U.S. patent application number 14/844348 was filed with the patent office on 2016-01-07 for location-aware selection of public transportation.
This patent application is currently assigned to MICROSOFT TECHNOLOGY LICENSING, LLP. The applicant listed for this patent is Microsoft Technology Licensing, LLP. Invention is credited to Dragos A. Manolescu.
Application Number | 20160005239 14/844348 |
Document ID | / |
Family ID | 42076429 |
Filed Date | 2016-01-07 |
United States Patent
Application |
20160005239 |
Kind Code |
A1 |
Manolescu; Dragos A. |
January 7, 2016 |
Location-Aware Selection of Public Transportation
Abstract
A mobile device such as a mobile phone, smart phone, personal
music player, handheld game device and the like that is configured
to be location-aware through GPS (Global Positioning System), cell
tower positioning, or other means of determining location, is
provided with a public transportation selector functionality that
interfaces with one or more on-line public transportation schedule
services. The public transportation selector passes the location of
a user of the mobile device, the user's destination, and the
targeted arrival time to the schedule services which responsively
return information including, for example, station/stop location
information, route identifier, departure and arrival times, and
fare costs. The public transportation selector aggregates schedule
information provided by the services for presentation to the user
through a user interface on the mobile device. The user can then
select the desired public transportation option and be provided
with directions to the appropriate station or stop.
Inventors: |
Manolescu; Dragos A.;
(Kirkland, WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Microsoft Technology Licensing, LLP |
Redmond |
WA |
US |
|
|
Assignee: |
MICROSOFT TECHNOLOGY LICENSING,
LLP
Redmond
WA
|
Family ID: |
42076429 |
Appl. No.: |
14/844348 |
Filed: |
September 3, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12244656 |
Oct 2, 2008 |
9159238 |
|
|
14844348 |
|
|
|
|
Current U.S.
Class: |
705/13 |
Current CPC
Class: |
G07B 15/02 20130101;
G06Q 50/30 20130101; H04W 4/02 20130101; G08G 1/20 20130101 |
International
Class: |
G07B 15/02 20060101
G07B015/02 |
Claims
1. A computer-readable medium not comprising a propagated data
signal containing instructions which, when executed by one or more
processors on a mobile device associated with a user, implement a
transportation application for providing public transportation
options to the user, the transportation application comprising: a
service adapter, the service adapter configured to: interface with
one or more of a plurality of schedule services; receive public
transportation information from the one or more respective schedule
services of the plurality of schedule services in regard to a
destination; and store the received public transportation
information from the one or more respective schedule services in a
route database; a public transportation selector, the public
transportation selector configured to provide a set of
transportation options to the user in response to a query regarding
transportation from a start location to a destination location with
a target time of arrival at the destination location, wherein the
public transportation selector determines the set of transportation
options according to the received public transportation
information; and a user interface, the user interface configured to
present the set of transportation options provided by the public
transportation selector to the user.
2. The computer-readable medium of claim 1, wherein the
transportation application further comprises a location module that
interfaces with location-aware functionality disposed in the mobile
device, the location module identifying the present location of the
mobile phone to the public transportation selector.
3. The computer-readable medium of claim 2, wherein the
transportation application further comprises a scheduling module,
the scheduling module configured to interface with scheduling data
having applicability to the user, the scheduling data including at
least one of an appointment, a calendar, a contact, or a task.
4. The computer-readable medium of claim 3, wherein the scheduling
module is further configured to generate the query according to the
scheduling data having applicability to the user.
5. The computer-readable medium of claim 3, wherein the
transportation application further comprises a user profile
configured for storing profile data that is collected about the
user.
6. The computer-readable medium of claim 5, wherein at least one of
the route database, scheduling module, or user profile is used by
the public transportation selector for filtering transportation
information from a schedule service of the plurality of schedule
services.
7. The computer-readable medium of claim 1, wherein the location
functionality is one of a global positioning system (GPS) or a cell
tower positioning functionality.
8. The computer-readable medium of claim 1, wherein the
transportation application further comprises a payment module, the
payment module being configured to facilitate an electronic payment
of a fare associated with a public transportation route.
9. The computer-readable medium of claim 8, wherein the public
transportation selector applies one or more heuristics to the
information from the plurality of schedule services to optimize the
public transportation options presented to the user through the
user interface.
10. A method, configured for execution on a mobile device, for
identifying and presenting public transportation information to a
user associated with the mobile device, the method comprising the
steps of: obtaining public transportation information of one or
more types of public transportation that are available for use
within a given geographic region storing the public transportation
information in a route database; receiving a query, the query
requesting route information for navigating to a target destination
to arrive at a target arrival time at the target destination;
identifying one or more transportation options of the public
transportation information from the route database, the one or more
transportation options for navigation to the target destination to
arrive at the target arrival time at the target destination; and
presenting the one or more transportation options to the user via
the mobile device.
11. The method of claim 10 further comprising: receiving a
selection of a first transportation option of the one or more
transportation options for navigation to the target destination to
arrive at the target arrival time at the target destination;
transacting a purchase between a public transportation provider
associated with the first transportation option and the user
associated with the mobile device.
12. The method of claim 10, wherein each of the one or more
transportation options for navigation to the target destination to
arrive at the target arrival time at the target destination include
at least one public transportation service.
13. The method of claim 12, wherein the least one public
transportation service comprise one of a bus, a rail, a light rail,
a subway, a trolley, a streetcar, a tram, a ferry, or a water
taxi.
14. The method of claim 10, wherein the public transportation
information is obtained by the mobile device from a plurality of
schedule services via a wireless data network.
15. The method of claim 10, wherein identifying one or more
transportation options of the public transportation information
from the route database comprises identifying one or more
transportation options of the public transportation information
from the route database and a source information, the one or more
transportation options for navigation to the target destination
from the source location to arrive at the target arrival time at
the target destination.
16. The method of claim 15 further comprising obtaining a present
location information of the mobile device from a location-aware
functionality disposed in the mobile device, wherein the present
location is the source location.
17. The method of claim 15, further comprising receiving the source
location from the user associated with the mobile device.
18. The method of claim 10 further comprising obtaining scheduling
data having applicability to the user of the mobile device, the
scheduling data including at least one of an appointment, a
calendar, a contact, or a task.
19. The method of claim 18, wherein the query is automatically
generated according to the scheduling data having applicability to
the user.
20. A mobile device associated with a user and configured to
provide transportation information to the user, the mobile device
comprising: a location module disposed in the mobile device for
determining location information of the mobile device; a route
database, the route database configured to store public
transportation information from one or more schedule services; and
a transportation application, the transportation application
comprising: one or more of service adapters, wherein each of the
one or more service adapters interfaces over a network with at
least one schedule service of a plurality of schedule services to
receive public transportation information from the at least one
schedule service of the plurality of schedule services, and stores
the public transportation information in the route database; and a
public transportation selector, wherein the public transportation
selector provides transportation options for navigating to a target
destination to arrive at a target time according to the public
transportation information in the route database in response to a
query identifying the target destination and the target time.
Description
BACKGROUND
[0001] People often rely on public transportation in many parts of
the world as a safe, efficient, and cost effective way to travel in
increasingly crowded urban and suburban areas. But it can often be
difficult to quickly identify the available means of public
transportation, particularly, for example, in unfamiliar geographic
areas, or at times of the day that are not typical or usual for the
traveler. Even if the traveler can find a bus or subway station, it
is not always straightforward to determine which route to take that
will ensure that the traveler will arrive at the desired
destination at the desired time.
SUMMARY
[0002] A mobile device such as a mobile phone, smart phone,
personal music player, handheld game device, and the like, that is
configured to be location-aware through GPS (Global Positioning
System), cell tower positioning, or other means of determining
location, is provided with a public transportation selector
functionality (e.g., implemented using a software application) that
interfaces with one or more on-line public transportation schedule
services. The public transportation selector passes the location of
a user of the mobile device, the user's destination, and the
targeted arrival time to the schedule services which responsively
return information including, for example, station/stop location
information, route identifier (e.g., bus number, subway line,
etc.), departure and arrival times, and fare costs relating to the
available transportation options which may include bus, train,
subway, ferry, and other forms of public transportation. The public
transportation selector aggregates schedule information provided by
the services for presentation to the user through a user interface
("UI") on the mobile device. The user can then select the desired
public transportation option and be provided with directions to the
appropriate station or stop.
[0003] In various illustrative examples, the user inputs a desired
destination through the UI. Alternatively, the destination may be
identified automatically through an interface with the user's
scheduling tool (e.g., appointment book or calendar application) on
the mobile device. Actual transit times may be collected and stored
in a route database so that the public transportation selector may
optimize the transportation options presented to the user.
Published route information from the public transportation schedule
services, stored user preferences, appointment and contact data,
and/or user profile information may also be utilized when
performing the optimization. In addition, the public transportation
selector may utilize such information when generating suggested
points of interest that the user may wish to visit on the way to
the station or along the route from the station to the destination.
The public transportation selector may also be configured with a
functionality to enable the user to pay for the public
transportation fare or make a reservation right from the mobile
device.
[0004] Advantageously, the present location-aware selection of
public transportation provides users with an easy to use way to
find public transportation that meets their needs. The interfaces
between the public transportation selector and other
functionalities on the mobile device, such as scheduling
applications and user preferences/profile data stores, further
enable effective route selection and optimization options to be
automatically and transparently generated for the user. The user
can thus effectively utilize public transportation in a way that
suits their particular needs and preferences.
[0005] This Summary is provided to introduce a selection of
concepts in a simplified form that are further described below in
the Detailed Description. This Summary is not intended to identify
key features or essential features of the claimed subject matter,
nor is it intended to be used as an aid in determining the scope of
the claimed subject matter.
DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 shows an illustrative public transportation
environment in which the present location-aware selection of public
transportation may be practiced;
[0007] FIG. 2 is a simplified functional block diagram of a
transportation application that is configured to run on a mobile
device;
[0008] FIG. 3 shows an illustrative communication flow between the
transportation application and a transportation schedule service in
an example usage scenario;
[0009] FIG. 4 shows an illustrative communication flow between the
transportation application and the mobile device user in an example
usage scenario; and
[0010] FIG. 5 shows an illustrative public transportation route
that is annotated with points of interest.
[0011] Like reference numerals indicate like elements in the
drawings.
DETAILED DESCRIPTION
[0012] FIG. 1 shows an illustrative public transportation
environment 100 in which the present location-aware selection of
public transportation may be practiced. In the environment 100, a
user 102 employs a location-aware mobile device 105 such as a
mobile phone, smart phone, PDA (personal data assistant), handheld
game device, handheld computer, pocket PC (personal computer),
portable media player such as those which can play MP3 (Moving
Pictures Expert Group, MPEG-1, audio layer 3) files, or device
which integrates several of such functions. It is noted that these
types of mobile devices are intended to be illustrative and that
other types of mobile devices may also be used in the present
arrangement as may be required to meet the needs of a particular
implementation.
[0013] The mobile device 105 may be configured with
location-awareness using a variety of conventional techniques.
These may include, for example, the use of GPS in which location is
determined through a triangulation calculation based on signals
from a network of satellites (as representatively indicated by
reference numeral 112).
[0014] Alternatively, cell tower positioning may be utilized to
approximate the position of the mobile device 105 by comparing the
relative signal strength between the mobile device and multiple
antenna towers (as representatively indicated by reference numeral
116). While cell tower positioning is a less accurate technology
compared with GPS, it may still provide sufficient accuracy in many
cases to provide location-awareness to the mobile device 105 in the
present application. In addition, cell tower positioning often
provides superior location determination compared with GPS when
mobile devices are used indoors. In some implementations, it may be
desirable to use both GPS and cell tower positioning technologies.
It is emphasized that the foregoing examples of location-awareness
are intended to be illustrative only and that other methodologies
may also be utilized as may be required to meet the needs of a
particular implementation.
[0015] The mobile device 105 is further configured for wireless
communication using a mobile data network to gain access to
resources that are located on a public network such as the Internet
120. The mobile data network could be arranged, for example, in
accordance with GPRS (General Packet Radio Service), EVDO
(Evolution Data Optimized), UMTS (Universal Mobile
Telecommunications System), or other known arrangements. In
alternative implementations, the resources may be accessed via
private network infrastructure such as VPN (virtual private
networks).
[0016] The Internet-accessible resources include public
transportation schedule services 124 which include, in this
illustrative example, a bus schedule service 124.sub.1, a train
schedule service 124.sub.2, and transportation schedule service
124.sub.N named "other" which is intended to represent a service
that covers other forms of public transportation. These include,
for example (but are not necessarily limited to) trains, light rail
conveyances, subway, trams, trolleys, streetcars, ferries, water
taxis, and similar types of transportation that may be provided by
public or private entities for the benefit of the general
public.
[0017] The transportation services 124 are configured to support
databases of information that pertain to their respective type of
transportation. So, for example, the bus schedule service 124.sub.1
will typically have access to bus routes, schedules, fare, and
other information (e.g., general passenger, station, or
accessibility information, the availability of special services,
etc.) for one or more bus lines or providers that may service a
particular geographic region. Such data can be populated into the
databases using any of a variety of conventional methods including
manual and automated data capture methods using schedule
information that is typically published by the transportation
provider.
[0018] It is noted that while separate schedule services 124 are
shown in FIG. 1, in some implementations, the services may be
combined or consolidated. For example, a single schedule service
124 might be used to provide information about more than one type
of transportation. There is no requirement that schedule services
be implemented on a one-to-one basis with the available types of
transportation.
[0019] The location-aware mobile device 105 can interact with the
transportation services 124 to receive schedule, public
transportation station or stop locations, route identifiers (e.g.,
bus number, subway line, ferry dock number, etc.), fare or ticket
price, and other information from the services in response to a
query or request from the device. The query will typically specify
the location of the user, the user's destination, and the desired
time of arrival. The mobile device 105 can thus receive, for
example, a list of transit options, directions to route the user
102 (as indicated by reference numeral 130) to the station or stop
136 of a train, bus, subway, etc., that is near to the location of
the user 102 and identify the appropriate line, number, or route
that can take him or her to the destination in the desired
timeframe, and fare information.
[0020] More specifically, as shown in FIG. 2, the mobile device 105
includes a transportation application 202 that is configured to
interact with one or more of the transportation services 124 to
enable the present public transportation selection feature set when
run on the device. Typically, the transportation application 202
will run as software code on the mobile device 105, although it can
also be implemented using firmware and/or hardware-based solution,
or combinations of software, firmware, and hardware in some
implementations. In addition, the transportation application 105
can be supported by the mobile device 105 under various "software
as services" models where all or a portion of the application runs
on a remote server.
[0021] In this example, the transportation application is
architected, as shown in FIG. 2, using a number of components.
However, it is emphasized that the particular components shown in
FIG. 2 and described below are intended to be illustrative and that
the functionality supported therein may be provided by components
or modules other than those shown, or be allocated among the
components in a different manner than that described.
[0022] The transportation application 202 includes a public
transportation selector 209 that is configured to provide the core
location-aware selection functionality. The user 102 interacts with
the public transportation selector through a UI 211, typically
through support of a graphical display and a means for input
capture. A location module 215 provides the interface to the
location-aware hardware in the mobile device such as GPS or cell
tower positioning components.
[0023] A group of service adapters 223 provide interfaces 225 over
the wireless data network to the respective schedule services 124
on the Internet 120 (FIG. 1). In particular, as shown, a service
adapter (bus) 223.sub.1 provides an interface 225.sub.1 to the bus
schedule service 124.sub.1. Similarly, the service adapter (train)
223.sub.2 provides an interface 225.sub.2 to the train schedule
service 124.sub.2. And, the service adapter (other) 223.sub.N
provides an interface 225.sub.N to the other schedule service
124.sub.N. The particular number and type of service adapters 223
utilized in any given implementation can vary from that shown in
FIG. 2. In addition, service adapters can be created by third
parties (i.e., parties other than a mobile device maker,
transportation application provider, or schedule service provider)
and utilized to enhance the capabilities of the present arrangement
in some applications.
[0024] A route database 230 is utilized locally on the mobile
device 105 to store route information that is downloaded from the
schedule services as well as to provide a store for actual transit
times experienced by the user 102 when following a particular
transportation route. Alternatively, the actual transit times can
be collected for other users for a variety of routes at some
central collection point (such as a data server) and then uploaded
to the route database. As described in more detail below, such
historical transit times can be utilized by the public
transportation selector, alone or in combination with other data,
as part of the optimization of transportation options that are
presented to the user 102 through the UI 211.
[0025] A scheduling module 235 is configured to provide an
interface to the user's scheduling or appointment application that
may be running on the mobile device 105. For example, the user may
be running an instance of Microsoft Outlook.RTM. Mobile on the
mobile device 105 to manage e-mail, calendars, contacts, and tasks.
The scheduling module 235 enables the public transportation
selector 209 to obtain information about the user's schedule and
appointments. Typically the user will be provided with an
opportunity to synchronize such information with the transportation
application. Knowledge of the user's schedule and appointments,
including for example, the time and location of such appointments,
can assist the public transportation selector 209 to transparently
(i.e., without requiring an affirmative or explicit action on the
part of the user 102) recognize a need for the user to be at a
particular place at a particular time. The public transportation
selector 209 can then provide an appropriate set of transportation
options that are responsive to such need.
[0026] In a similar manner as with the scheduling module, a user
profile 241 may be optionally utilized (as indicated by its dashed
outline) to further enhance the public transportation selector's
ability to provide transportation options to the user 102 that
suits the user's needs. As above, the user 102 will typically be
provided with an opportunity to opt in to the collection of data
regarding the user's usage of the mobile device 105.
[0027] Various techniques and heuristics can be employed to infer a
user preference from collected profile data. In some cases, user
preferences may be explicitly solicited by the transportation
application, or may be set, modified or updated by the user 102.
For example, if the user profile or preference indicates that buses
are most preferred by the user, and subways least preferred, the
public transportation selector 209 can act appropriately when
providing transportation options for a given usage scenario.
[0028] Also optionally utilized in the transportation application
202 is the payment module 248. This module can be used in those
implementations where infrastructure is in place to facilitate
secure payment transactions to the transportation providers (either
directly or via third party service) using the mobile device 105.
Such transactions can utilize a pre-payment system or be tied to a
traditional credit card, for example. Alternatively, the use of
other known electronic payment systems such as near field
communications ("NFC") may also be facilitated by the payment
module 248 using the mobile device 105 as a delivery mechanism. In
some implementations, it may be desirable to collect a fee for
facilitating the ticket purchase transaction using the mobile
device 105. The recipient of the fee may be one of the schedule
service providers, or a third party, for example.
[0029] Turning now to FIG. 3, an illustrative flow of
communications between the transportation application 202 and a
schedule service 124 is shown for an example usage scenario. The
scenario starts by a service adapter 223 in the transportation
application 202 registering with its corresponding schedule service
124 (as indicated by reference numeral 310). Thus, for example, the
service adapter (bus) 2231 will register with the bus schedule
service 1241 and so forth. The service adapter 223 will typically
perform the registration using a simple handshake with the service
124 when there is need to pull schedule data or status updates
about service affecting issues. For example, the user 102 may work
through the UI 211 to explicitly make a request to locate public
transportation. Or, the scheduling module 235 may identify an
upcoming appointment at a distant location which the public
transportation selector 209 uses as an automatic trigger to
initiate the registration in a manner that is transparent to the
user.
[0030] The location module 215 determines the current location of
the mobile device 105 (and hence the location of the user 102)
which is relayed via the service adapter 223 along with the
destination and desired arrival time to the schedule service 124
(320). In response, the schedule service 124 will return a
selection of possible transportation routes with associated
schedules for the particular public transportation type and the
corresponding fee information back to the service adapter 223
(330).
[0031] The route identifies the starting and destination points
and, in most cases, schedule information that includes published or
approximate departure and arrival times for each route. The number,
line, route, or other identifying information will also be provided
(e.g., bus #6, the yellow subway line, ferry slip 3, etc.)
Typically, as multiple service adapters are used to interface with
multiple transportation schedule services, the steps of
registration, reporting, and information return are performed with
each service adapter and schedule service pair, and the
transportation application 202 may assemble a multi-segment route
out of segments provided by different types of transportation--for
example, a leg of the route by ferry, then by bus, then by subway.
Depending upon the particular circumstances, it may be possible for
a relatively large amount of information to be passed back from the
various transportation schedule services 124 to the transportation
application 202 running on the mobile device 105. That is, there
may be multiple ways for the user 102 to get to a particular
destination using different forms of public transportation that
traverse different routes, and within some reasonable interval to
the desired arrival time.
[0032] Other types of information can also be returned by a
schedule service 124. While it may vary by implementation, the
information may be drawn from the information databases supported
by the schedule service 124 and include general passenger, station,
or accessibility information, the availability of special services,
etc., as noted above.
[0033] The public transportation selector 209 is responsible for
taking the route and schedule information returned from the
schedule services 124 and presenting it to the user through the UI
211. In some cases, as noted above, the information can aggregate a
multi-segment route using different public transportation types.
FIG. 4 shows an illustrative flow of communications between the
transportation application 202 and the user 102 for the example
usage scenario shown in FIG. 3 and described above.
[0034] Generally in most implementations it will be desirable for
the public transportation selector 209 to apply rules or heuristics
to sort or rank order the returned information. In this way the
public transportation selector 209 can optimize the routes and
schedules to present the user 102 with a select subset of all the
available transportation options (as indicated by reference numeral
410). Alternatively, the optimization can be performed remotely by
one of the schedule services 124 or by another remote service.
Optimization may also be shared between the locally running
transportation application and a remote service.
[0035] The optimization techniques may vary by implementation. In
some cases, the public transportation selector 209 will consider
locally stored information such as historic transit times from the
route database 230, or profile and/or user preferences from the
user profile 241.
[0036] With the route database 230, the stored historical transit
times for a particular route (or any other information provided by
the user) enable the public transportation selector 209 to
determine the likelihood of a transportation option getting the
user 102 to the destination by the desired time. Thus, for example,
while published schedule information may indicate that a bus
running on a city's west side route is supposed to arrive at the
central station at 2 pm, the historical data may show that this bus
typically runs late.
[0037] The historical transit time information may also be
particularly useful for public transportation that does not provide
published departure and arrival times. With some subway lines, for
example, subway cars arrive at each station on a periodic basis but
not at a set time. In this case, the historical transit time
information will typically help the public transportation selector
209 in determining whether that particular subway route is an
appropriate option to present to the user 102 and further enable
the public transportation selector to provide approximate departure
and/or arrival times.
[0038] The public transportation selector 209 may use data from the
user profile 241 to optimize route selection by filtering or
weighting transportation options based on explicitly generated user
preferences or preferences that may be inferred from the collected
user profile data. Thus, transportation by subway may be considered
a more optimized solution for the user 102 in light of the profile
or preference, even if a bus stop, for example, may be physically
closer to the user's current location at the time of the query.
Accordingly, the public transportation selector 209 will typically
rank order subway routes over bus routes when presenting
transportation options to the user 102 when it is determined that
subways are the user's preferred type of transportation.
[0039] When presented with the transportation options, the user 102
can work through the UI to pick an option that is desired and meets
the user's needs (420). Responsively to the user's selection of the
transportation option, station route information (i.e., direction)
will be provided through the UI 211 (430). The user 102 may also be
optionally presented with the ability to make an electronic payment
for the fare associated with the selected transportation option, or
make a reservation (440). In this case, the functionality from the
payment module 248 will typically be invoked.
[0040] As the user 102 makes the trip using the selected
transportation option, the actual transit time associated with the
route will be collected so that the route database 230 can be
updated. The transit time can be calculated once the location
module 215 indicates that the mobile device 105 (and hence the user
102 as well) has arrived at the destination.
[0041] Additional value-added features may also be advantageously
implemented using the present location-aware public transportation
selection arrangement. As shown in FIG. 5, the public
transportation selector 209 can annotate the station route
information 530 (i.e., the directions to the station or stop 136)
with various points of interest 535.sub.1, 2 . . . N along the
route. The points of interest 535 may vary by implementation and
may include, for example, friends of the user 102, retail stores,
museums, restaurants, and the like. The points of interest 535 can
be automatically generated by the public transportation selector
209 using locally available data. Alternatively, the points of
interest 535 can be generated remotely using an external
service.
[0042] So, for example, the public transportation selector 209
might determine from the user's contact list that is available from
the scheduling module 235 that a friend or acquaintance of the user
102 resides or works near the route to the station 136. If so, the
UI 211 can include an annotation with the station route information
530 that there is an opportunity for a visit with the friend or
acquaintance.
[0043] If the current time is close to a meal time, the public
transportation selector 209 may also include an annotation with the
station route information 530 that a restaurant that the user 102
may like is along the route to the station 136. The public
transportation selector 209 may use data from the user profile 241
when making this annotation.
[0044] If the scheduling module 235 indicates that the user 102 has
created a task to purchase a gift, for example, for a friend's
upcoming birthday, the public transportation selector 209 can make
an annotation that an appropriate retail store is along the route
to the station 136.
[0045] Data from the user profile 241 or scheduling module 235 may
be used in a similar manner as in the examples above to generate
annotations about other points of interest for the user 102 (e.g.,
museums, memorials, historical sites, recreation and entertainment,
and the like). Should the user 102 wish to take time to accommodate
a point of interest, the public transportation selector 209 can
re-query the schedule services 124, if necessary and then determine
additional transportation options that may be presented to the user
102 that take into account the additional time.
[0046] The constellation of potential points of interest 535 can be
stored locally in the mobile device 105 and be periodically updated
through interaction with a remote service, for example, so that the
annotations reflect current and valid information. Alternatively,
the points of interest 535 can be dynamically received in real time
by an appropriate query to the remote service.
[0047] The public transportation selector 209 can also be
configured to generate annotations that are applicable to the route
taken by the selected mode of public transportation. As shown in
FIG. 5, the transportation route information 541 may include
annotations of various points of interest 547.sub.1, 2 . . . N that
the user 102 may wish to visit along the transportation route to
the destination 550. The public transportation selector 209 can
utilize a similar methodology, as described above for annotating
station route information, when generating annotations for points
of interest 547 to the transportation route information 541. That
is, the public transportation selector 209 can take into account
locally available information such as data from the scheduling
module 235 and user profile 241 when making the annotation for the
points of interest 547. And, as with the example above, the public
transportation selector 209 can re-query the schedule services 124,
if necessary, and determine additional transportation options that
may be presented to the user 102 that take into account the
additional time required to accommodate a point of interest
547.
[0048] Although the subject matter has been described in language
specific to structural features and/or methodological acts, it is
to be understood that the subject matter defined in the appended
claims is not necessarily limited to the specific features or acts
described above. Rather, the specific features and acts described
above are disclosed as example forms of implementing the
claims.
* * * * *