Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

The present specification provides an electronic geolocation device
comprising a location sensor and a geolocation application configured to
record location data associated with said device. The device further
includes a processor configured to receive the location data and to
associate the location data with contextual data, and to export the
location data and contextual data in a data format native to an external
application.

Claims:

1. An electronic geolocation device comprising: a location sensor; a
processor connected to said location sensor; said processor further
configured to execute a geolocation application to periodically record
sampled location data received from said sensor; said processor further
configured to execute a service separate from said geolcation application
configured to associate contextual data with said location data; and,
said processor further configured to export said contextual data and said
location data from said service into a format native to an external
application.

2. The device of claim 1 wherein said external application is a calendar
application.

3. The device of claim 2 wherein said contextual data comprises at least
one of travel activity type, a starting location, a current location and
an ending location; a starting time corresponding to said starting
location and an ending time corresponding to said ending location and a
route map from said starting location to said ending location.

4. The device of claim 3 wherein said travel activity type is represented
with an appointment colour coding native to said calendar application.

5. The device of claim 3 wherein said travel activity type is represented
with a text value in a subject field that is native to said calendar
application.

6. The device of claim 3 wherein at least one of said starting location,
said current location, and said ending location is represented with text
in a location field native to said calendar application.

7. The device of claim 3 wherein said starting time is represented in a
starting time field native to said calendar application and said ending
time is represented in an ending time field native to said calendar
application.

8. The device of claim 3 wherein said route map is represented as at
least one of text or graphics in a notes field native to said calendar
application.

9. The device of claim 1 wherein said external application is a travel
log spreadsheet.

10. The device of claim 1 wherein said service is configured to access an
external mapping service to determine a route map corresponding to said
location data as part of said contextual data.

11. A geolocation method for an electronic device comprising: executing a
geolocation application on a processor configured to receive location
data from a location sensor connected to said processor; receiving at
said processor via said geolocation application periodically sampled
location data from said location sensor; associating contextual data with
said location data at a service separate from said geolocation
application; and, exporting said contextual data and said location data a
format native to an external application from said service that is
separate from said geolocation application.

12. The method of claim 11 wherein said external application is a
calendar application.

13. The method of claim 12 wherein said contextual data comprises at
least one of travel activity type, a starting location, a current
location and an ending location; a starting time corresponding to said
starting location and an ending time corresponding to said ending
location and a route map from said starting location to said ending
location.

14. The method of claim 13 wherein said travel activity type is
represented with an appointment colour coding native to said calendar
application.

15. The method of claim 13 wherein said travel activity type is
represented with a text value in a subject field that is native to said
calendar application.

16. The method of claim 13 wherein at least one of said starting
location, said current location, and said ending location is represented
with text in a location field native to said calendar application.

17. The method of claim 13 wherein said starting time is represented in a
starting time field native to said calendar application and said ending
time is represented in an ending time field native to said calendar
application.

18. The method of claim 13 wherein said route map is represented as at
least one of text or graphics in a notes field native to said calendar
application.

19. The method of claim 11 wherein said external application is a travel
log spreadsheet.

20. A non-transitory computer readable medium configured to store a
plurality of programming instructions executable on a processor of an
electronic device; said programming instructions comprising a method
comprising: executing a geolocation application on a processor configured
to receive location data from a location sensor connected to said
processor; receiving at said processor via said geolocation application
periodically sampled location data from said location sensor; associating
contextual data with said location data at a service separate from said
geolocation application; and, exporting said contextual data and said
location data a format native to an external application from said
service that is separate from said geolocation application.

Description:

FIELD

[0001] The present specification relates generally to computing devices
and more specifically relates to an enhanced geolocation device.

BACKGROUND

[0002] Portable computing devices are increasingly powerful and can offer
location services through global positioning system (GPS) and other
technologies. However, an overwhelming amount of location data can be
generated.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003]FIG. 1 is a schematic representation of a front view of an
exemplary portable electronic device.

[0004] FIG. 2 is a block diagram of the electronic components of the
device shown in FIG. 1.

[0005]FIG. 3 is a flow chart depicting a method for social media
communications.

[0006]FIG. 4 is a flow chart depicting possible blocks for performing one
of the blocks of the method of FIG. 3.

[0007] FIGS. 5A and 5B show an example view from a calendar application
generated as a result of performing the method of FIG. 3.

[0008]FIG. 6 shows another example view from a calendar application
generated as a result of performing the method of FIG. 3.

[0009]FIG. 7 shows a flowchart depicting a method of determining an
activity type that can be used as part of the method of FIG. 3.

[0010]FIG. 8 shows an example view from another application that can be
generated as result of performing the method of FIG. 3.

[0011]FIG. 9 shows a schematic representation of the relationships
between various software objects shown in the block diagram of FIG. 2.

[0012]FIG. 10 shows a schematic representation of a system for enhanced
geolocation incorporating a variation on the device of FIG. 2.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0013] An aspect of this specification provides an electronic geolocation
device comprising: a location sensor; a processor connected to said
location sensor; said processor further configured to execute a
geolocation application to periodically record sampled location data
received from said sensor; said processor further configured to execute a
service separate from said geolocation application configured to
associate contextual data with said location data; and, said processor
further configured to export said contextual data and said location data
from said service into a format native to an external application.

[0014] The external application can be a calendar application. The
contextual data can comprise at least one of travel activity type, a
starting location, a current location and an ending location; a starting
time corresponding to said starting location and an ending time
corresponding to said ending location and a route map from said starting
location to said ending location; a "Completed Trip" data set or a "in
Progress Trip" data set. A "Completed Trip" data set can contain at least
one travel activity type, a starting location and an end location. An "In
Progress Trip" contain at least one activity type, a starting location, a
current location and a projected/estimated end location.

[0015] The travel activity type can be represented with an appointment
colour coding native to said calendar application.

[0016] The travel activity type can be represented with a text value in a
subject field that is native to said calendar application.

[0017] The at least one of said starting location, said current location,
and said ending location can be represented with text in a location field
native to said calendar application.

[0018] The starting time can be represented in a starting time field
native to said calendar application and said ending time is represented
in an ending time field native to said calendar application.

[0019] The route map can be represented as at least one of text or
graphics in a notes field native to said calendar application.

[0020] The external application can be a travel log spreadsheet.

[0021] The service can be configured to access an external mapping service
to determine a route map corresponding to said location data as part of
said contextual data.

[0022] Another aspect of this specification provides a geolocation method
for an electronic device comprising: executing a geolocation application
on a processor configured to receive location data from a location sensor
connected to said processor; receiving at said processor via said
geolocation application periodically sampled location data from said
location sensor; associating contextual data with said location data at a
service separate from said geolocation application; and, exporting said
contextual data and said location data a format native to an external
application from said service that is separate from said geolocation
application.

[0023] Another aspect of this specification provides a computer readable
medium executable on an electronic device comprising a plurality of
programming instructions according to any of the foregoing.

[0024]FIG. 1 is a schematic representation of a non-limiting example of a
portable electronic device 50 which can be used for enhanced geolocation,
as discussed in greater detail below. It is to be understood that
portable electronic device 50 is an example, and it will be apparent to
those skilled in the art that a variety of different portable electronic
device structures are contemplated. Indeed variations on portable
electronic device 50 can include, without limitation, a cellular
telephone, a portable email paging device, a camera, a portable music
player, a portable video player, a personal digital assistant, a portable
book reader, a portable video game player, a tablet computer, a netbook
computer, or a laptop computer. Other contemplated variations include
devices which are not necessarily portable, such as desktop computers.

[0025] Referring to FIG. 1, device 50 comprises a chassis 54 that supports
a display 58. Display 58 can comprise one or more light emitters such as
an array of light emitting diodes (LED), liquid crystals, plasma cells,
or organic light emitting diodes (OLED). Other types of light emitters
are contemplated. A touch-sensitive membrane 62 is overlaid on display 58
to thereby provide an input device for device 50. As a non-limiting
example, device 50 can be configured to selectively show or hide a
virtual keyboard 64. Other types of input devices can be provided on
chassis 54, other than touch membrane 62, or in addition to touch
membrane 62, are contemplated. For example, a physical keyboard, or
touch-pad, or joystick or trackball or track-wheel, a microphone, or
optical camera or any one or more of them can be provided, in addition to
or in lieu of touch membrane 62. Such other components may, if desired,
be "slide-out" components. In a present implementation, device 50 also
comprises a speaker 66 for generating audio output. Speaker 66 may be
implemented as, or augmented with, a wired or wireless headset or both.

[0026] FIG. 2 shows a schematic block diagram of the electronic components
of device 50. It should be emphasized that the structure in FIG. 2 is a
non-limiting example. In FIG. 2, device 50 includes input devices touch
membrane 62 and a location sensor 68. (As noted above, other input
devices are contemplated even if not expressly discussed herein.) Touch
membrane 62 has been discussed above. Location sensor 68 can be based on
a GPS receiver which receives signals from GPS satellites and resolves
those signals into location coordinates. Location sensor 68 can also be
based on base station triangulation methods, or base station identifiers
or both. Other types of location sensors that are functionally similar or
equivalent to those expressly discussed herein are contemplated. Multiple
location sensors can also be provided.

[0027] Input from location sensor 60 and touch membrane 62 is received at
a processor 100. In variations, processor 100 may be implemented as a
plurality of processors or multi-core processors or both. Processor 100
can be configured to execute different programming instructions that can
be responsive to the input received via the one or more input devices. To
fulfill its programming functions, processor 100 is also configured to
communicate with at least one non-volatile storage unit 104 (e.g.
Erasable Electronic Programmable Read Only Memory ("EEPROM"), Flash
Memory) and at least one volatile storage unit 108 (e.g. random access
memory ("RAM")). Programming instructions that implement the functional
teachings of device 50 as described herein are typically maintained,
persistently, in non-volatile storage unit 104 and used by processor 100
which makes appropriate utilization of volatile storage 108 during the
execution of such programming instructions.

[0028] Processor 100 in turn is also configured to control display 58 and
speaker 66 and any other output devices that may be provided in device
50, also in accordance with different programming instructions and
responsive to different input receive from the input devices.

[0029] Processor 100 also connects to a network interface 112, which can
be implemented in a present embodiment as a radio configured to
communicate over a wireless link, although in variants device 50 can also
include a network interface for communicating over a wired link. Network
interface 112 can thus be generalized as a further input/output device
that can be utilized by processor 100 to fulfill various programming
instructions. It will be understood that interface 112 is configured to
correspond with the network architecture that defines such a link.
Present, commonly employed network architectures for such a link include,
but are not limited to, Global System for Mobile communication ("GSM"),
General Packet Relay Service ("GPRS"), Enhanced Data Rates for GSM
Evolution ("EDGE"), 3G, High Speed Packet Access ("HSPA"), Code Division
Multiple Access ("CDMA"), Evolution-Data Optimized ("EVDO"), Institute of
Electrical and Electronic Engineers ("IEEE") standard 802.11,
Bluetooth® or any of their variants or successors. It is also
contemplated each network interface 112 can include multiple radios to
accommodate the different protocols that may be used to simultaneously or
individually communicate over different types of links. Where location
sensor 68 utilizes base station identifiers or base station
triangulation, then such network architectures can be accommodated within
such a location sensor 68.

[0030] As will become apparent further below, device 50 can be implemented
with different configurations than described, omitting certain input
devices or including extra input devices, and likewise omitting certain
output devices or including extra input devices.

[0031] Device 50 is configured to maintain, within non-volatile storage
104, a geolocation application 124, a service 128, a calendar application
132 and optionally, one or more additional applications 136. Geolocation
application 124, service 128 and calendar application 132 and the one or
more additional applications 136 can be pre-stored in non-volatile
storage 104 upon manufacture of device 50, or downloaded via network
interface 112 and saved on non-volatile storage 104 at any time
subsequent to manufacture of device 50.

[0032] Processor 100 is configured to execute geolocation application 124,
accessing non-volatile storage 104 and volatile storage 108 as needed. As
will be explained further below, geolocation application 124 can be used
for, amongst other things, recording location data of locations visited
by device 50 as detected by location sensor 68. In certain
implementations, geolocation application 124 is also configured to
associate contextual data with the recorded data and to store recorded
geolocation data in an external application such as calendar application
132.

[0033] Referring now to FIG. 3, a flowchart depicting a method for
geolocation is indicated generally at 300. Method 300 is one way in which
geolocation application 124 can be implemented. It is to be emphasized,
however, that method 300 and need not be performed in the exact sequence
as shown, hence the elements of method 300 are referred to herein as
"blocks" rather than "steps". Method 300 can be implemented on a variety
of different devices, including device 50. Accordingly, to help explain
method 300 it will be explained in relation to device 50.

[0034] Block 305 comprises activating a location sensor. When implemented
on device 50, block 305 can be effected by geolocation application 124
sending an instruction to sensor 68 via processor 100 to begin receiving
location information from location sensor 68. Again, such location
information can be in any suitable form, such as coordinates, base
station identifiers. For purposes of further illustrative discussion, it
will be assumed that location sensor 68 is a GPS receiver and therefore
location information is in the form of GPS coordinates, but those skilled
in the art are to appreciate that discussion of GPS coordinates is a
non-limiting example.

[0035] Block 310 comprises recording sensed location information. When
implemented on device 50, block 310 can be effected by geolocation
application 124 receiving location coordinates from sensor 68 and
recording those coordinates in non-volatile storage 104 or volatile
storage 108 or both. The frequency with which location coordinates are
sampled is not particularly limited, but in general is intended to strike
a balance between substantially accurate continuous recording of location
while being sensitive to the memory and other resource constraints of
device 50. Indeed, in a theoretical device 50 with an infinite amount of
storage and processing power, then the sampling frequency could be
virtually continuous.

[0036] Block 315 comprises associating the location data with contextual
data. The contextual data can be meta-data that relates to a plurality of
location data points, or can be specific to each location data point. The
contextual data can be stored in non-volatile storage 104 or volatile
storage 108 or both in association with the coordinates recorded at block
310. Such contextual data comprises at least time stamps that correspond
to the location samples recorded at block 310. Note that the term "time"
in time stamps is intended to encompass both a calendar date and a time
of day for that date, and can also be based on Coordinated Universal Time
(UTC).

[0037] Contextual data can also comprise any other data that can be
associated with the location data. The determination of what other data
is of interest is not particularly limited, however, in certain
implementations, the contextual data can be based on a particular
external application. Indeed, FIG. 4 shows a non-limiting example of how
block 315 can be implemented. Specifically, block 316 contemplates
determining an external application, block 317 comprises determining data
types for that external application, and block 318 comprises determining
contextual data for those data types determined at block 317. A
non-limiting example, discussed further below, of an external application
includes calendar application 132.

[0038] Referring again to FIG. 3, block 320 comprises exporting data from
block 315 in a format that is native to an external application. When
block 315 is implemented according to block 316, block 317 and block 318
in FIG. 4, then the external application of block 320 can correspond to
the external application determined at block 316.

[0039] Having described method 300 generally, various specific but
non-limiting example implementations of method 300 will now be discussed.
In a first example, device 50 and method 300 are used in conjunction with
calendar application 132 to provide rich travel logging functionality.
Table I shows a non-limiting example of how existing fields in calendar
application 132 can be populated at block 320 using method 300 as a rich
travel log.

[0040] Continuing with the example of using method 300 as a rich travel
log, block 305 thus comprises activating the location sensor 68 as
discussed above, and block 310 comprises recording location data as
discussed above. Block 315 can be implemented according to the blocks
shown in FIG. 4, and thus block 316 comprises determining an external
application for use as a rich travel log. The result of block 316 can be
the determination that calendar application 132 can be used for the
actual logging. Block 317 comprises determining data types for the
external application. The result of performing block 317 can be all or
part of the contents of Table I, or a variation thereon.

[0041] Block 318 comprises determining the actual contextual data that
corresponds to the data types determined at block 317. Table II shows an
example of contents that can be determined at block 318.

TABLE-US-00002
TABLE II
Travel Log for External Calendar Application
Example Travel Log Populated at block 318
External Application Example Contents
Field Field Field Usage determined at block 318
1 Colour Coding Non-textual descriptor for Green
travel activity type
2 Subject Textual descriptor for travel Motor vehicle Trip
activity type
3 Location One or both of starting point Woolwich Ontario to
and ending point for travel Waterloo Ontario
4 Start Time Start time and date of travel 08:30/06:15:2009
5 End Time End time and date of travel 08:41/06:15:2009
6 Notes Map of Route from starting See field 432 and field 436
point to ending point of FIG. 6

[0042] Returning again to FIG. 3, block 320 contemplates the exporting of
the data shown in Table II to calendar application 132. FIG. 5 and FIG. 6
shows the results of the exporting according to the specific example in
Table II. More specifically, FIG. 5 shows an example week view 400 from
calendar application 132. Week view 400 includes an entry 404 on Monday
Jun. 15, 2009 that reflects a portion of the contents of Table II. FIG. 6
shows an example day view 408 of entry 404, which includes all of the
contents of Table II. More specifically, field 412 of day view 408
corresponds to the example contents of Field 1 from Table II; field 416
of day view 408 corresponds to the example contents of Field 2 from Table
II; field 420 of day view 408 corresponds to the example contents of
Field 3 from Table II; field 424 of day view 408 corresponds to the
example contents of Field 4 from Table II; field 428 of day view 408
corresponds to the example contents of Field 5 from Table II; field 432
of day view 408 corresponds to the textual portion of Field 6 from Table
II; field 436 of day view 408 corresponds to the graphical portion of
Field 6 from Table II.

[0043] Having studied Table II, FIG. 5 and FIG. 6, it will now be
appreciated that the contents thereof were recorded using method 300
based on an automobile trip that commenced at 8:30 AM on Monday Jun. 15,
2009 at 139 Young Street in St. Jacob's Ontario, and ended at 8:41 AM on
Monday Jun. 15, 2009 at 455 Phillip Street Waterloo Ontario. The specific
route shown in field 436 of FIG. 6 was recorded by periodic location
sampling at block 310, and the actual map itself was associated with the
sampled locations at block 315, accessing a third party mapping service
to associate specific recorded coordinates with more traditional
addressing information as shown in field 432 of FIG. 6 and field 436 of
FIG. 6.

[0044] The means by which the activity type from Field 1 and Field 2 of
Table II is not particularly limited. Referring now to FIG. 7, however, a
non-limiting example of a method for determining an activity type is
indicated generally at 500. Method 500 can be used as part of, for
example, block 318 of method 300. Block 505 comprises determining a route
type. The route type can be determined by comparing the stored locations
from block 315 with electronic maps of the type that are maintained by
NavTEQ® or Google® or the like. Indeed, referring again to field
436 of FIG. 6, it can be seen that the recorded route corresponded with
Highway Number 8, which can be identified as a motorway that would
normally be used by motorized vehicles or possibly bicycles. Block 510
comprises determining the overall timing that was taken to complete the
route. Referring to field 424 and field 428 and field 432 of FIG. 6, it
can be determined that the overall time, as logged, was about eleven
minutes to travel 7.1 kilometres. A speed can therefore be determined
which can be used to determine that the speed averaged about 38.7
kilometres per hour which is more consistent with the travel time of a
motorized vehicle and not a bicycle. (However, method 500 can be modified
to provide a query such as "Please indicate the mode of transportation
for this trip" in order to provide a means to resolve any ambiguity as to
the mode of transport). Block 515 thus comprises making a final
determination of the travel activity type, which can then be used to
populate field 1 and field 2 of Table II.

[0045] Method 500 can also be used to infer walking as the travel activity
type, where the speed of travel is consistent with walking and where the
route that was travelled is associated with walking or hiking or running.
Method 500 can thus be used to infer running as the travel activity type,
where the speed of travel is consistent with running and where the route
that was travelled is associated with walking or hiking or running.
Method 500 can thus be used to infer bicycling as the travel activity
type, where the speed of travel is consistent with bicycling and where
the route that was travelled is associated with walking or hiking or
running or bicycling. Method 500 can thus be used to infer a motor
vehicle as the travel activity type, where the speed of travel is
consistent with a motor vehicle and where the route that was travelled is
associated with motor vehicles.

[0046] Method 500 can also be used to infer a train as the travel activity
type, where the speed of travel is consistent with a train and where the
route that was travelled is associated with train track. Further
validation for inferring a train can be based on published rail
schedules, which can be automatically accessed by device 50.

[0047] Method 500 can also be used to infer an airplane as the travel
activity type, where the speed of travel is consistent with an airplane
and where the route that was travelled is associated with an airplane. Of
note is that in the air travel example it would be expected that device
50 may be shut off after take-off and turned on again after landing at
the destination airport, and thus there may be a lack of intermediate
travel points. Further validation for inferring an airplane trip can be
based on published airline schedules, which can be automatically accessed
by device 50.

[0048] Method 500 can also be varied to infer that the activity was not a
travel activity but, for example, a telephone call or some other
application that is local to device 50. For example, where device 50 is
equipped with a telephone function, then method 300 can be used to log
telephone calls in calendar application 132 when each call is completed.
This can also be extended to logging usage of other applications on
device 50, such as texting applications, word processors, or video games
or others.

[0049] In another example, device 50 and method 300 can be used in
conjunction with other applications 136. FIG. 8 shows an example of one
other application 136, specifically identified as a spreadsheet
application 136a. Spreadsheet application 136a comprises a travel log for
the week of Jun. 14, 2009 in tabular format, which summarizes all logged
events for a given that identified week. The left column defines various
events that correspond generally to the examples provided in Table I. The
bottom rows provide sub-totals for groupings of activities in the left
column. A total number of minutes for a particular activity or event for
a given day is provided in each cell. The far right column provides a
weekly total. Of particular note is the very bottom row which
contemplates a determination of carbon dioxide emissions associated with
each of those activities, which provides but one example of how the
features of this specification can be extended to novel data logging.
Those skilled in the art will appreciate that the other time periods and
formats for the spreadsheet are not particularly limited.

[0050] Other applications 136 will now occur to those skilled in the art,
such as accounting packages, time tracking packages and the like.

[0051] Referring now to FIG. 9, a schematic representation of how
geolocation application 124 can interact with service 128, which in turn
can interact with calendar application 132 or other applications 136. It
is to be noted that service 128 can be omitted, or its functions
incorporated directly into geolocation application 124, or incorporated
directly into calendar application 132 or other applications 136.
However, it is presently contemplated that service 128 is provided to
intermediate between geolocation application 124 and applications such as
calendar application 132 and other applications 136. More specifically,
service 128 can be configured to access native programming interfaces
within calendar application 132 and other applications 136, as well as to
access native programming interfaces within geolocation application 124.
In this manner, geolocation application 124 can be deployed independently
from deployment of calendar application 132 or other applications 136,
and vice versa.

[0052] While the foregoing provides certain non-limiting example
embodiments, it should be understood that combinations, subsets, and
variations of the foregoing are contemplated. For example, FIG. 10 shows
an enhanced geolocation system indicated generally at 150b. System 150b
comprises a device 50b, which is a variation on device 50. Thus, like
elements associated with device 50b bear like references to the device 50
counterpart, except followed by the suffix "b". System 50b also comprises
a calendar server 154b that connects to device 50b via a network 158b. A
client machine 162b (which is optional) also connects to network 158b.

[0053] The nature of network 158b is not particularly limited, and can be
comprised of a private network or a public network or combinations
thereof. Furthermore, network 158b can be comprised of one or more
network topologies, including the Internet or other packet switched
network, or any one or more of the network topologies discussed above in
relation to network interface 112.

[0054] Server 154b maintains a calendaring server application 166b which
works in conjunction with calendar application 128b to maintain a copy of
all calendar records associated with device 50b. Client machine 162b
maintains its own calendar application 170b which can access all calendar
records on either device 50b and server 154b.

Patent applications by RESEARCH IN MOTION LIMITED

Patent applications in class Including route searching or determining

Patent applications in all subclasses Including route searching or determining