CA 02710643 2010-07-20
SYSTEM AND METHOD FOR CREATION AND MANAGEMENT
OF LOCATION INFORMATION
TECHNICAL FIELD
100011 This application generally relates to location information, and more
particularly, to a system and method for creating and managing location
information so
that location based policies can be determined.
BACKGROUND
[0002] Every day, millions of people log in to their computers using an
associated
password and username. By logging in and using such personalized information,
the
presence or absence of the person at a computer terminal can be determined. In
addition, presence or absence of a person can be determined through a phone
system.
For instance, calls made by a person can be used to automatically detect
presence of
the caller's location.
CA 02710643 2010-07-20
10003] Because these detection devices have limited ranges, however, other
devices
have been used for locating a person of interest. Motion sensor systems,
through
infrared technology, can determine the presence or absence of a person by
detecting
movements within a limited range. Global positioning systems (GPS), often
provided in
many cell phones, can also be used to determine the location of a person.
Through
these global positioning systems, latitude, longitude, and even the elevation
of the
person can be determined. In other applications, a wireless fidelity (WiFi)
detector can
be used. While providing a greater area for detection, these detectors often
provide
uncertain and ambiguous information.
100041 Recently, "availability" features were introduced into presence and
absence
determination systems. Availability features provide the user with options
describing
their current status. A user could be "unavailable," "available," "busy," "in
a meeting,"
"on a call," etc. As an illustrative example, systems would consider a user
"unavailable"
if the computer system failed to detect mouse or keyboard movements for a
prolonged
period of time. Systems were also programmed to go "busy" when associated
applications, such as electronic calendars, indicated so. By using the
availability
feature, other parties interested in the whereabouts of the user would be able
to check
the user's status.
[0005] As millions of users are introduced to these types of systems,
creating and
maintaining location information and location based policies can become
overwhelming.
Many systems have failed because they have been built with an optimistic
expectation
of a user's involvement. Typically, users are not willing to spend large
amounts of time
on training for new systems for which they have not, as yet, seen clear
benefits.
Furthermore, previous systems were rigid in the way they stored location
information
2
CA 02710643 2010-07-20
and policies and often did not provide for minor adjustments. A need therefore
exists to
provide a system and method for overcoming the previously described
limitations as
well as overcoming limitations present within today's systems.
BRIEF DESCRIPTION OF DRAWINGS
[0006] The novel features believed to be characteristic of the application
are set forth
in the appended claims. In the descriptions that follow, like parts are marked
throughout
the specification and drawings with the same numerals, respectively. The
drawing
figures are not necessarily drawn to scale and certain figures can be shown in
exaggerated or generalized form in the interest of clarity and conciseness.
The
application itself, however, as well as a preferred mode of use, further
objectives and
advantages thereof, will be best understood by reference to the following
detailed
description of illustrative embodiments when read in conjunction with the
accompanying
drawings, wherein:
[0007] FIGURE 1 depicts a pictorial illustration of an exemplary system for
detecting
a person within a range of a detector in accordance with one aspect of the
present
application;
[0008] FIGURE 2 provides a diagram exemplifying multiple detectors within
typical
locations of a building in accordance with one aspect of the present
application;
[0009] FIGURE 3 illustrates interactions between multiple location types to
derive
exemplary location information about a person in accordance with one aspect of
the
present application;
[0010] FIGURE 4 shows an illustrative block diagram for degrading the
confidence of
location data received from an exemplary detection system in accordance with
one
3
CA 02710643 2010-07-20
aspect of the present application;
[0011] FIGURE 5 diagrams an exemplary flow chart providing processes for
degrading the confidence value of location data as well as handling
conflicting
information from multiple sensors in accordance with one aspect of the present
application;
[0012] FIGURE 6 shows a pictorial representation of multiple illustrative
sensors
detecting a person and consolidating the location in accordance with one
aspect of the
present application;
[0013] FIGURE 7 is a flow chart providing illustrative processes for
approximating a
location of a person based on the multiple sensors in accordance with one
aspect of the
present application;
[0014] FIGURE 8 provides exemplary applications that can use the
approximations
in accordance with one aspect of the present application;
[0015] FIGURE 9 shows an illustrative Source Location Type converted into a
Destination Location Type in accordance with one aspect of the present
application;
[0016] FIGURE 10 depicts exemplary direct and indirect parameterizations
between
Location Types in accordance with one aspect of the present application;
[0017] FIGURE 11 represents a typical query structure for providing
relational
information in accordance with one aspect of the present application;
[0018] FIGURE 12 shows a block diagram depicting policies applied to
multiple
users in accordance with one aspect of the present application;
[0019] FIGURE 13 provides an illustrative automated tool for creation and
management of location information in accordance with one aspect of the
present
application;
4
CA 02710643 2014-05-16
[0020] FIGURE 14 represents illustrative personal tools for interfacing
policies in
accordance with one aspect of the present application; and
100211 FIGURE 15 is a representative graphical user interface used to
illustrate
behavior provided by the exemplary personal tool in accordance with one aspect
of the
present application.
DESCRIPTION OF THE APPLICATION
[0022] The description set forth below in connection with the appended
drawings is
intended as a description of presently-preferred embodiments of the
application and is
not intended to represent the only forms in which the present application can
be
constructed and/or utilized. The description sets forth the functions and the
sequence
of steps for constructing and operating the application in connection with the
illustrated
embodiments. It is to be understood, that the scope of the claims should not
be limited
by the preferred embodiments set forth in the examples, but should be given
the
broadest interpretation consistent with the description as a whole.
[0023] Overview
100241 Generally described, the present application relates to an
integrated system,
and more particularly, to a system and method for providing approximations of
a
person's location to a number of interested parties wherein the approximations
are
based upon inherent inaccuracies related to a detection device. Furthermore,
the
present application relates to a system and method for creating and managing
location
information so that location based policies can be determined. In one
illustrative
embodiment, a set of locations such as country, state, city, building, and
room can be
placed in a hierarchy. Each location within the hierarchy can include a
precision level,
CA 02710643 2010-07-20
the precision level associated with an accuracy level of a detector involved
for placing a
person within that particular location. Typically, the broader the location,
the lower the
accuracy level of a detector for placing a person within that location and
similarly, the
more specific the location, the higher the accuracy level for placing a person
within that
location.
[0025] When a detector receives location information, the system can
traverse
through the locations and their associated precision levels to approximate the
correct
type of location within the hierarchy using the accuracy level of the detector
that
received the location information. For example, a wireless fidelity (WiFi)
detector can
have an accuracy level for approximating a person's location within a country,
state,
city, and building based on its precision levels, but does not have an
accuracy level for
determining whether the person is within a room. In turn, an associated
management
device could receive information corresponding to those approximations to
provide
centralized information where distribution of that information to a number of
devices
operated by interested parties can take place.
[0026] In essence, the system presented herein discloses a system that
receives
and analyzes sensor data and creates estimations about a user location. Due to
the
inherent inaccuracies of sensor readings and detection devices, locations can
be
associated with a confidence value that can show that a person is within the
location.
As will become apparent from the following description, multiple embodiments
for the
present application are presented and are not limited to the illustration
provided above.
In one embodiment, the system can evaluate location data from multiple
detectors and
approximate the location using and combining that information. In other
embodiments,
the system can determine a location of a person and provide a confidence level
for that
6
CA 02710643 2010-07-20
determination. In another embodiment, the system can also degrade confidence
values
assigned to the approximation as a function of time. In other embodiments, the
system
can determine a location of a person and provide a confidence level for that
determination. In one embodiment, the system can analyze ambiguous location
information.
[0027] The present application also provides for the creation and
management of
user location policies and data. In one embodiment, automated tools and
personal tools
can be provided. These tools can alleviate the onerous and expensive task of
updating
the policies and data. The automated tools can use existing information within
company
databases to create and manage standard user locations. The personal tools can
allow
the user to personally manage their own locations through a graphical user
interface.
Typically, each of these tools can utilize global positioning system
information to track
the current location of the user. The information can then be used to
determine physical
locations to a certain degree.
[0028] The above embodiments represent a small set of applications in which
the
system can be used. One skilled in the relevant art will appreciate that the
present
application can be extended to multiple embodiments beyond those described
above.
[0029] Location Types and Subtypes
100301 Integrated into the system can be Location Types that are used to
evaluate
location information, the Location Types being suited for various forms of
interaction.
Syntaxes and semantics can be used for the Location Types. With relation to
the
present application, but not limiting hereto, syntax can refer to principles
and rules for
constructing a Location Type. As will be shown, Location Types can include
multiple
7
CA 02710643 2010-07-20
,
,
syntaxes, each of which can be suited to different interaction spaces.
Semantics can
refer to, but is not limited to, policies for linking various Location Types.
100311 A Location Type can be a simple parameter. The simple
parameter can be
associated with a simple numeric quantity or value. In the alternative, and as
will be
described within the present application, the Location Type can be
multifaceted.
Location Types typically describe the location of a person in such a way to
effectively
manage interaction and thus enable effective collaboration with such
information. One
skilled in the relevant art will appreciate that one Location Type can be
preferred over
another Location type dependent on the type of application that uses the
Location Type.
For example, one Location Type, a Political/Physical Location Type, can
describe a
general location, while another Location Type, an Enterprise Location Type,
can be
used for an employer/employee/visitor relationship. Other Location Types can
include,
but are not limited to, a Raw Sensor Data Location Type and a User/Social
Location
Type. In one exemplary embodiment, the Location Types can include the
following:
<Raw Sensor>
<Political/Physical>
<Enterprise>
<User/Social>
[0032] Generally, each Location Type can include a number of
Subtypes. The
Subtypes can be hierarchically categorized by means of aggregation and
specialization.
A specific location can be described in the syntax of the Subtypes at each
level in the
hierarchy. To better exemplify Subtypes, each Subtype for each Location Type
can be
defined by the following:
<Raw Sensor>
8
CA 02710643 2010-07-20
,
,
<Political/Physical>
<<Country>>
City
<<District
<<Street>>
<<Building>>
Floor>>
Room
<Enterprise>
<<Premises>>
<<Campus>>
Building>>
<<Room
<User/Social>
Venue
<<Building>>
Room
[0033]
As shown above, but not limiting the present application, Raw Sensor
Location Type does not include Subtypes. Political/Physical Location Type can
include
Country Subtype, City Subtype, District Subtype, Street Subtype, Building
Subtype,
Floor Subtype, and Room Subtype. Enterprise Location Type can include Premises
Subtype, Campus Subtype, Building Subtype, and Room Subtype. User/Social
Location Type can include Venue Subtype, Building Subtype, and Room Subtype.
It will
9
CA 02710643 2010-07-20
,
µ
become apparent to one of ordinary skill in the art the uses and features of
each of the
Location Types and Subtypes from the discussion below.
100341
In some embodiments, Subtypes of the Location Types can be restricted
to a
certain set or range of values. In the Physical/Political Location Type, for
example, the
Room Subtype can be restricted with room numbers used in the building. In
another
example, using the Enterprise Location Type, the Premises Subtype can be
restricted to
the values of "On" or "Off' representing policies that can affect employees
differently if
they are "On" or "Off' company premises. The Campus Subtype and Building
Subtype
can also be restricted to a specific list of real estate properties that are
used for
company operations. In the Enterprise Location Type, it could be useful to
provide
more functional values. For example, these could include: Office, Meeting
Room,
Hallway, Stairs, Male Dressing Room, and Female Dressing Room.
[0035]
Within the User Location Type, Venue Subtype can take the values of
"Work"
or "Home" to indicate two distinct environments in which communication and
collaboration features can be expected to function differently. The Room
Subtype can
take values in the form of Office, Boss's Office, Meeting Room, Dressing Room,
etc.
The syntax for the Location Types can be created such that the instantiated
Location
Types can be of use for further applications and policies.
[0036]
In typical embodiments, Enterprise Location Types can apply policies
to the
location of employees and visitors within its premises.
For example, through the
Enterprise Location Type, the system can determine whether an employee is
present
for work or that a visitor has moved into a restricted area. In another
example, the User
Location Type can have policies that modulate their communication features to
handle
their calls differently if they are in their own office as differentiated when
they are in the
CA 02710643 2010-07-20
,
,
office of a colleague. One skilled in the relevant art will appreciate that
there can be a
number of different syntaxes to describe different Location Types.
Furthermore,
numerous Subtypes can also be associated with the Location Types.
[0037] The User Location Type can be created with a syntax that
would specify
locations in a way that could be useful for further policies and applications.
The User
Location Type can be used to indicate suitable forms of human interaction
i.e.,
indicating behaviors of users. In one example, a user in a meeting room can
have their
call forwarding operate differently if they were in their own office.
[0038] As depicted above, the Enterprise Location Type and the User
Location Type
show that the concept of a Location Type can extend beyond the typical
Political/Physical Location Type. Generally, the Location Type does not simply
denote
a point in space, but can be extended to spaces of interaction between
enterprises and
people as they collaborate for business and social purposes. One skilled in
the relevant
art will appreciate that the concept of Location Types is not limited to those
specifically
provided within the present application. Furthermore, numerous applications of
the
Location Type can be derived from those syntaxes expressed above
[0039] With specific reference to the Political/Physical Location Type, the
aggregation hierarchy is explained in more detail now. As recited above, the
Political/Physical Location Type can include Country Subtype, City Subtype,
District
Subtype, Street Subtype, Building Subtype, Floor Subtype, and Room Subtype. In
one
example of the aggregation, the Floor Subtype incorporates one or more Room
Subtypes. In addition, the Floor Subtype can incorporate a Hallway Subtype.
[0040] In some embodiments, the Subtypes can be specialized. For
example, the
Building Subtype can include a specialized value of "Residence" or "Business"
11
CA 02710643 2010-07-20
premises. The Room Subtype can be specialized into office, meeting room,
dressing
room, etc. The dressing room can further be specialized into male and female
dressing
rooms. The specialization can continue as far as it is valuable to the syntax
of the
Location Type. Through the syntax described above, various Location Types can
be
instantiated.
[0041]
Using the concepts provided above, Location Types can be instantiated to
facilitate the management of location data. As will be shown below, the
Location Type
can be instantiated from location data received from a detector. Typically,
the location
data can be stored within the Location Type Data, which will be further
described below.
For example, an instantiation of the Political/Physical Location Type can be:
<Political/Physical>
Country>><<United States>>
City>> New York City
<<District>><<Midtown Manhattan>>
Street>><<34th Street
<<Building>><<Empire State Building>>
Floor 56th>,
Room 56123
[0042]
As shown, the use of a hierarchy allows the creation of a syntax for the
representation of a location. The syntax could represent a location as a
sequence of
ordered pairs, key/value pairs, otherwise known as a tuple. Tuples can be
stored in
computer memory for access by other applications.
[0043]
One skilled in the relevant art will appreciate that the representation of a
location described above is not intended to be complete.
For example, the
12
CA 02710643 2010-07-20
Political/Physical Location Type does not indicate a position within a room.
Rather the
scope of the present application is intended to define a location such that it
can be
useful for subsequent applications. The scope of the present application is
intended to
define illustrative Location Types and Subtypes that could provide location
information
for many applications.
[0044] Interaction Between Multiple Location Types
[0045] The examples provided above describe exemplary syntaxes for the
Location
Types and Subtypes. Associated with the syntaxes can be a set of semantics,
which
define policies within Location Types and between multiple Location Types.
Often,
having policies for those Location Types can enhance communication and
collaboration
applications.
[0046] As shown above, a Physical/Political Location Type can be
instantiated from
location data. Similarly, the Enterprise Location Type and User Location Type
can be
derived from the same location data. In one embodiment, however, Location
Types can
use the data within other instantiated Location Types to fill in their own
instantiation. In
another embodiment, multiple Location Types can be used to pinpoint a more
precise
location of a person. For example, the instantiated Enterprise Location Type
can place
a person within a campus to a certainty. In addition, the Political/Physical
Location
Type can place a person within a room to a certainty. Using both the
Enterprise
Location Type and the Political/Physical Location Type, the person can be
placed within
their own office of the campus to a degree of confidence that is derived from
the
confidences of the Enterprise Location Type and the Political/Physical
Location Type.
[0047] As illustrated, the confidence in Location Types that are derived
from other
Location Types can be derived from the confidences within these Location
Types. In
13
CA 02710643 2010-07-20
,
addition, policies in the new Location Types can take information from their
Location
Type Data to improve confidence intervals. In one example of the semantics
provided
by the present application, the Political/Physical Location Type can place a
person in
one of six rooms. If the Enterprise Location Type includes Location Type Data
that
indicates that one of these rooms is a utility room that is off limits, then
the system can
sharpen its confidence declarations that have been provided by the
Physical/Political
Location Type.
[0048]
In another example of semantics that can govern Location Types, if the
system is aware that a person is a female and one of the rooms is a male
dressing
room for the Enterprise Location Type, then the confidence declarations can be
further
refined. Location placements can also be refined by placing a person within
their own
office rather than a colleague's.
[0049]
Confidence refinement policies can also be used in conjunction with a
calendar feature.
This can affect a person's likelihood of being at any one place
dependent on information provided within a calendar. While several semantics
or
policies were provided above, one skilled in the relevant art will appreciate
that there
are numerous ways to interact the different Location Types and their Subtypes
together.
In addition, there are a variety of variables and features that can be used to
approximate a person's location through the syntax described above.
[0050] Accuracy
[0051]
In the present application, and with reference now to FIGURE 1, the system
100 described herein relates to approximating a person's location, and in
typical
embodiments, using the syntaxes and semantics described above. For
illustrative
purposes, a general location like "Work" or "Chandler Office" can be given a
low
14
CA 02710643 2010-07-20
,
,
precision level and a specific location like "Cubicle" could be given a higher
precision
level. The system 100 could then determine which set of locations it can
detect based
on how accurate the information it received from the detector 102. For
example, a
phone having WiFi, instead of a global positioning system (GPS), could receive
less
accurate data causing the system 100 to differentiate only between work and
home, but
not individual offices or conference rooms.
100521 As shown, the exemplary system 100 can include a detector
102, an optional
location device 104, a range of uncertainty 106, and a server 108. The server
can
include a shared memory 110, Location Type Policies 112, and Location Type
Data
114. These components are understood by one skilled in the relevant art to be
illustrative and not to be construed as limiting to the present application.
The system
100 described in FIGURE 1 provides a single detector 102, but as will be shown
below,
the system 100 can include multiple types of detectors 102, which can include,
but is
not limited to, light detectors, motion detectors, temperature detectors,
magnetic field
detectors, vibration detectors, pressure detectors, sound detectors, etc.
10053] In some embodiments, a location device 104 can be used to
identify a person
to a detector 102. Examples of such location devices 104 can include a key
card, an
identification badge, or some other type of technology that can be used to
alert the
detector 102. Often, these types of devices 104 can use infrared technology.
100541 Generally described, precision levels define what kind of
detectors 102 can
detect in one location. Typically, locations require an accuracy from a
detector 102 for
the person to be located within that location. If the proper detector 102 is
not used, that
detector 102 generally cannot determine whether that person is within that
location. In
CA 02710643 2010-07-20
,
,
some embodiments, the system 100 could provide a certainty level, but does not
guarantee that the person is located within that location.
[0055] In the shown embodiment, the detector 102 uses a WiFi
system. The WiFi
detector 102 can detect a location device 104 within a range of the WiFi
detector 102.
The coverage of the WiFi detector 102 can include an area as small as a single
room or
as large as many square miles. The signal propagated by the WiFi detector 102
typically becomes less certain or accurate after a certain range, otherwise
known as a
range of uncertainty 106. A location device 104 can be considered located if
it is within
the range of a WiFi base station (for example, within a spherical radius of
ninety
meters). Alternatively a person can be located by an infrared detector 102
within a
single room. Typical room materials are opaque to infrared radiation and so if
a
person's location device 104 is detected then they should be within the room.
[0056] While a WiFi detector 102 was described above, one skilled
in the relevant art
will appreciate that there are numerous other possibilities for providing
location data to
the system 100. In one embodiment, the location device 104 can be attached to
a
phone, cellular phone, personal digital assistant, or some other electronic
device to
detect the location of a person. In addition, light systems can detect the
location of a
person. Still yet, when a user logs into their computer, location data can be
detected.
Multiple variations can exist for detecting the location of a person. The
location device
104 can include, but is not limited to, a wireless badge, a WiFi or Bluetooth
device, an
infrared badge etc.
100571 Continuing with FIGURE 1, each detector 102 can place a
person within a
range of locations. For example, the WiFi detector 102 can place a person's
location
16
CA 02710643 2010-07-20
within a general range of areas, but not to specific locations. In other
embodiments, a
GPS detector 102 can typically detect a person with more accuracy.
[0058] The location data received from a detector 102 can take many forms.
For
example, a GPS detector 102 can provide a geographic latitude and longitude
with an
elevation. This can be used in determining what floor a person is on within a
building.
For a WiFi detector 102, it can simply be the assertion that a user's
transmitter is within
range of a specific base station. A triangulated WiFi detector 102, can use
the form of
ranging information from a set of base stations, usually three or more.
[0059] Connected to detector 102 is a management device 108 for storing the
location data. The management device 108 can include a single server or
multiple
servers receiving and transmitting location data typically through a network.
One skilled
in the art would appreciate that a network can include the Internet, an
intranet network,
a wide area network (WAN), a local area network (LAN), personal area network
(PAN),
wireless local area network (WLAN), and the like. Through the management
device
108, the location data can be processed, stored, and accessed by multiple
applications.
[0060] The management device 108 can place the location data into shared
memory
110. Often, this can be done using a conventional publish/subscribe mechanism.
On
the management device 108, which can access the shared memory 110, a set of
Location Type Policies 112 can use the received location data from the
detector 102.
[0061] In typical embodiments, the Location Type Policies 112 can convert
the
location data into an instantiated location in the syntax of its Location Type
as described
above. To do so, the Location Type Policies 112 can make use of the Location
Type
Data 114. The Location Type Data 114 can include the location of the detector
102
within a building and the expected range of a signal. Furthermore, other
Location Type
17
CA 02710643 2010-07-20
,
Data 114 can include a person's location, activity, co-presence (i.e. current
companions), business/social relationship with their current companions and
other
parameters which can be useful. The Location Type Data 114 can be in multiple
forms,
it can be an absolute position and range expressed numerically, or it can be a
list of
locations in which it is possible that the signal can be received.
100621 Often, associated with the detectors 102 are potential error
bounds on any
specific location determination. For the WiFi example, an instantiated
location may not
be more accurate than the expected range of the WiFi signal.
100631 FIGURE 2 provides a system 100 exemplifying multiple
detectors 102 within
typical locations of a building 200 in accordance with one aspect of the
present
application. For illustrative purposes, several people are shown encompassed
within
the building 200, including person 202 and person 204. Person 202 can be
detected by
a WiFi detector 102 within the range of uncertainty 106. The WiFi detector
102, as
shown, can have a detection area of several rooms and outside of the building
200.
[0064] After receiving location data for person 202 from WiFi
detector 102, a
Location Type can be instantiated, such as a Political/Physical Location Type.
As
described above, the Political/Physical Location Type can include a hierarchy
of
locations ranging from a Country Subtype to a Room Subtype. Multiple locations
can
be instantiated that can or cannot be a person's location. Thus, a person's
location can
be described by a list of location instantiations.
[0065] Within FIGURE 2, a detector 102 having a smaller range of
uncertainty 106 is
presented. As shown, the detector 102 can have an accuracy of a single room.
In one
embodiment, the detector 102 can take the form of an infrared detector.
Alternatively,
the detector 102 can track a person 204 logging into their computer or be a
motion
18
CA 02710643 2010-07-20
sensor. The detector 102 can incorporate numerous types of technologies that
can
detect a person 204 in a single room or small area. While having a small range
of
uncertainty 106, the accuracy of the detector 102 for person 204 is typically
more
accurate than the WiFi detector 102 for persons 202 or detectors that can
cover a large
range as described above. In some detectors 102, such as a GPS, additional
parameters can be provided such as speed, elevation, etc. Through these
parameters
different types of Location Types can be instantiated.
[0066] After the Location Type is instantiated, system 100 generally places
the
instantiations on the shared memory 110. As will be shown below, many
applications
can use the instantiations.
[0067] Confidence Determinations
[0068] As described above, a user's location can be a list of instantiated
Location
Types and Subtypes as shown by the examples provided above. In addition,
confidence determinations of a person's location can be attached to the
Location Types
and more particularly, the Subtypes. Referring to the WiFi detector 102
described
above, and in particular person 202, the confidence determinations for a
Political/Physical Location type can include the following:
<Political/Physical>
<<Country>><<United States>><<Confidence>><<Certain>>
<<City>><<New York City <<Confidence>><< Certain >>
<<District>><<Midtown Manhattan>><<Confidence>><< Certain >>
<<Street 34th Street>><<Confidence>><< Certain >>
<<Building>><<Empire State Building>><<Confidence>><< Certain >>
<<Floor 56th>><<Confidence Certain >>
19
CA 02710643 2010-07-20
Room>><<56123 Confidence>> Possible>>
[0069] As shown in FIGURE 2, the range of uncertainty 106 can place person
202
within a hallway, one of six rooms or outside the building. However, person
202 is
unambiguously within the United States, New York City and the Empire State
Building.
Thus, the Location Type Polices 112 can annotate the location list for person
202 to
indicate that these location Subtypes have been determined with certainty. In
one
embodiment, confidence determinations can use values such as "Certain,"
"Likely,"
"Unlikely," "Possible," etc. Alternatively, or in addition thereto, percentage
values can
be used, such as 80% to 94%.
[0070] Continuing the previous example, the Political/Physical Location
Type builds
upon the Location Type hierarchy disclosed early. If person 202 can
unambiguously be
placed in a Subtype of a certain extent then that person 202 can be placed
unambiguously in Subtypes of a greater extent. In other words, and using the
previous
example, if person 202 is unambiguously in the Empire State Building Subtype,
then
that person 202 is unambiguously in the New York City Subtype and the United
States
Subtype. Furthermore, if there is ambiguity in the person's 202 location in a
Subtype,
then this can be propagated to Subtypes of a lesser extent. So the confidence
that
person 202 can be placed in a room is shared among the rooms and hallway that
person 202 can be possibly in.
100711 In the previous example, a person 202 was detected by a WiFi
detector 102.
Generally, WiFi detectors 102 cannot detect a person with a resolution less
than a floor
of a building 200. Nonetheless, Location Type Policies 112 can be used to
further
determine the likelihood of a person 202 being in any one of the instantiated
room
Subtypes in the location list. One skilled in the relevant art will appreciate
that this can
CA 02710643 2010-07-20
be performed in a number of different ways and can make use of data stored in
the
Location Type Data 114.
[0072] In one embodiment, the determination can be performed using a
relative area
of each room to the total area of the floor plan in which a person 202 was
detected. As
a result, the larger a room on the floor, the more likely that a person 202
can be located
in that room. This can be pre-calculated for each detector 102 and kept in the
Location
Type Data 114 or it can be calculated from raw floor data each time.
[0073] Using the confidence and accuracy concepts described above, a
person's
location can be a list of one or more instantiated Location Types with each
instantiated
Subtype being provided with a confidence value or declaration. For example, a
person
202 can be associated with a Political/Physical Location Type, an Enterprise
Location
Type, or User/Social Location Type, to name a few.
[0074] With reference now to FIGURE 3, interactions between multiple
Location
Types found in shared memory 110 to derive location approximations for a
person is
presented in accordance with one aspect of the present application. As shown
above, a
Political/Physical Location Type was derived from location data. In addition
to, the
Enterprise Location Type and User Location Type can similarly be derived from
the
location data.
[0075] Often, however, system 100 can provide a more efficient way for
instantiating
Location Types by using the information within other Location Types. Location
Type
Policies 112 can be made aware of other Location Types. For example, and as
shown
in FIGURE 3, if the Physical/Political Location Type Policies 112 place a
person in a
single room with high confidence, the Enterprise Location Type Policies 112
can take
this Location Type along with those confidence determinations within the
21
CA 02710643 2010-07-20
Physical/Political Location Type and couple it with data about the Enterprise
Location
Type and its Location Type Data 114 to place that person in an office.
Similarly, the
User/Social Location Type can use the Location Type Policies 112 and data from
its
Location Type Data 114 to place the person in their own office with a degree
of
confidence that is derived from the confidence of the other Location Types.
[0076] As illustrated above, confidences in Location Types can be derived
from
confidence determinations in other Location Types. Location Type Polices 112
can be
able to use knowledge taken from their Location Type Data 114 to improve these
confidence determinations. In one example, the Physical/Political Location
Type
Policies 112 can place a person in one of six rooms. However, if the
Enterprise Location
Type Policies 112 include Location Type Data 114 that indicates that one of
these
rooms is a utility room that is off limits to certain personnel, then the
system 100 can
sharpen the confidence determinations that have been provided by the
Physical/Political
Location Type.
[0077] In a related example, if the User/Social Location Type Policies 112
are aware
that the person is a female and one of the rooms is a male dressing room for
the
Enterprise Location Type, then the confidence determinations can be further
sharpened.
More specific Location Type Polices 112 can also be provided. For example, a
user is
more likely to be in their own office than that of a colleague. Confidence
determinations
in the User/Social Location Type can be further sharpened by putting less
confidence
that a user can be in a colleague's office rather than their own office. These
confidence
refinement policies can also be used with a user's calendar.
[0078] Degradation of Confidence Determinations
[0079] Returning to FIGURE 2, a person 204 can be detected by a detector
102 with
22
CA 02710643 2010-07-20
the accuracy of a single room indicated by the range of uncertainty 106. This
is shown
with an infrared sensor but it could have also been provided using data from a
hot
desking feature. The location data indicated that the person 204 was within
the single
room with a confidence level of certainty. Often, as time passes, the
credibility of the
confidence determination can degrade as a time-based function. After a period
of
several hours, the credibility given to such a declaration can be very low.
[0080]
Recent determinations can be given a high credibility as to their confidence
determination, while older determinations can be given a low confidence
determination.
Typically, the degradation of confidence can be used with technologies that do
not
periodically determine whether a person has left the area.
Rather, degrading
confidence determinations can work with technologies such as phone lines and
computer docking stations. The syntaxes and semantics for each of the Location
Types
can usefully take into account the degradation of confidence determinations.
[0081]
With reference now to FIGURE 4, confidence determinations can be
degraded through a variety of ways. In one embodiment, the Location Type
Policies
112 for a detector 102 can periodically apply a suitable degradation function
and update
the confidence determination with new values. Alternatively, the Location Type
Policies
112 can extend its syntax by adding a tag 402 indicating when the location
data was
taken. The degradation of confidence can then be performed by other
applications.
These applications can apply their own degradation functions that can be more
useful
for their specific purposes. An example of the syntax for a Political/Physical
Location
Type is shown below:
<Political/Physical>
Date>><<2009-11-03 Time <<10:11
23
CA 02710643 2010-07-20
Country>><<United States>><<Confidence>><<Certain>>
<<City>><<New York City>><<Confidence Certain >>
<<District>><<Midtown Manhattan>><<Confidence>><< Certain >>
<<Street>><<34th Street>><<Confidence Certain >>
<<Building>><<Empire State Building>><<Confidence>><< Certain >>
Floor 56th>> Confidence>><< Certain >>
<<Room>><<56123>><<Confidence>><<Possible>>
[0082]
Using the tag 402 above, several ways can be used to degrade the
confidence determinations for the Subtypes of the Political/Physical Location
Type. In
one embodiment, a suitable time-based degradation function can be used to
degrade
the confidence determinations periodically after its last valid location
determination.
Continuing with the hot desking example provided above, this degradation can
begin
immediately after the hot desking feature is exercised by the user. This
embodiment
takes into account that the person can have quickly left the room after a
brief call. In the
case of the WiFi determination, however, the WiFi detector 102 can know that
the
location device 104 or person is within range. Generally, and from the
examples
provided above, the degradation function does not take effect until the
detector 102
loses contact with the person. Often, the location and confidence
determinations by the
detector 102 can still be valid for a period of time. Even though the person
has left the
detection area indicated by the range of uncertainty 106, it can still be
declared, with
confidence, for a time that the person is still within the Empire State
Building, and for
longer times that the person is within New York City and the United States.
The same
is also true for the person using the hot desking. Thus, in some embodiments,
the use
of a confidence declaration with some method of indicating degradation can
provide
24
CA 02710643 2010-07-20
useful location information for extended periods of time.
[0083] Conflicts in Degraded Data
[0084] Often, there can be instances in which conflicts in Location Types,
Subtypes,
and confidence determinations occur. For example, when a person leaves the
office
and returns to their home, detectors 102 at the office can indicate that their
location is at
the office, but with degraded confidence. When the person arrives at home, the
detectors 102 can indicate that they are at home as well. A Location Selector
function,
in the system 100 or application, can use the date and time of day indication
to select
among these conflicting locations. Locations derived from more recent location
determinations can be preferred. Locations that conflict with more recent
location
determinations can be discounted.
[0085] In some embodiments, confidence degradation can be avoided if the
degradation capability is not implemented. In these embodiments, detectors 102
could
provide periodic determinations.
[0086] Unknown Location
[0087] Continuing with the example provided above, in some instances, a
person's
location is not known. If no detector 102 can provide a location for a user,
then specific
policies can be activated. Generally, there can be preferences set up if the
person
cannot be located at home or at the office or any other location.
[0088] FIGURE 5 diagrams an exemplary flow chart providing processes for
degrading the confidence determinations of location data as well as handling
conflicting
information from multiple detectors 102 in accordance with one aspect of the
present
application. The exemplary processes provided herein are for illustrative
purposes and
should not be construed as limiting to the scope of the present application.
CA 02710643 2010-07-20
,
[0089]
The process begins at block 500. At block 502, a detector 102 can receive
location data. The location data typically comes from either a location device
104 or a
person that is detected by the detector 102, or a combination thereof. The
location data
is then converted to a Location Type instantiation at block 504. Dependent on
the type
of location that the detector 102 is at, different Location Types can be
instantiated. For
example, if the location data is detected within a building, the
Political/Physical Location
Type can be used. In another example, an Enterprise Location Type can be
instantiated when the person is detected on a university's campus.
[0090]
Continuing with FIGURE 5, a time stamp or tag 402 can be inserted into the
instantiated Location Type at block 506. The tag 402 can indicate a date and
time the
location data was received by the detector 102. As shown, the tag 402 can
allow for the
degradation of a confidence determination for the location data received.
[0091]
At block 508, confidence determinations are applied to the instantiated
Location Types. Generally, these determinations are applied to the Subtypes of
the
instantiated Location Type. In one embodiment, the Subtypes can include values
of
"Certain," "Likely," "Unlikely," "Possible," etc. Alternatively or in addition
thereto,
percentage values can be used, such as 80% to 94%.
100921
At decision block 510, the system 100 determines whether any new location
data is received by detector 102. Often this is a result of a periodic update
by the
detector 102. If no update is available by the detector 102, the system 100 or
application degrades the confidence determination for the Location Type and
its
Subtypes at block 512. Typically, a time-based function is used based on the
tag 402
associated with the Location Type.
In other embodiments, the confidence
determinations can be degraded based on specific information related to the
detected
26
CA 02710643 2010-07-20
,
,
person.
[0093] At decision block 514, system 100 can determine whether a
person's
location is unknown. At this point, the Location Types confidence
determinations have
become uncertain, often as a result of a prolonged period of time passing. In
the
previous examples, this could occur when the person is neither located at
their house
nor at their office. If the person's location is unknown, then a policy is
implemented at
block 516. This policy can include set all Location Types to unknown or
uncertain. The
process then ends at block 518.
[0094] Returning to decision block 514, the process returns to
decision block 510
when the person's location is still known. Often this is a result of the
confidence
determination not falling below a threshold value.
[0095] At decision block 510, and when new location data from the
detector 102
has been received, the system continues with decision block 518. At decision
block
518 the system 100 or application determines whether there is a conflict with
a previous
instantiation. As described earlier, this can occur when the person moves from
their
office to their home. When no conflict is reported, the processes continue at
block 506.
Otherwise, the process goes to decision block 520.
[0096] At decision block 520, the system 100 determines whether the
previous
location data is older than the new location data. When it is, the process
returns to
block 504. Otherwise, the process returns to block 506.
[0097] Multiple Sensors and Location Selection
[0098] FIGURE 6 shows a pictorial representation of multiple
illustrative detectors
102 detecting a person and consolidating the location in accordance with one
aspect of
the present application. As described above, locations can be provided in the
syntaxes
27
CA 02710643 2010-07-20
of multiple interaction spaces, called Location Types. Location data can be
propagated
by semantics, possible policy-based, between multiple interaction spaces.
The
examples of Physical/Political Location Type, Enterprise Location Type, and
User/Social
Location Type have been provided for. However, these are examples and other
Location Types can be created as needed e.g., an interaction space for
collaboration
groups.
[0100]
In typical embodiments, confidence and degradation of confidence features
can be associated with the Location Types. Uncertainties in Location Types can
be
captured within the syntaxes of multiple interaction spaces. It has been shown
how this
confidence declaration can be propagated between interaction space syntaxes
and how
evidence within an interaction space can be use to sharpen or otherwise adjust
these
confidence declarations.
[0101]
The features provided above overcome the deficiencies previously described.
In particular, the system 100 and applications capture the inherent
uncertainties within
detectors 102. Multiple mutually ambiguous location determinations can be
considered,
which will now be described with respect to FIGURE 6.
[0102] Generally described, location data can be ambiguous.
The inherent
uncertainty in a location measurement can span different values in a Location
Type
Subtype. For example, a user can be specified as being in their own office at
the same
time as them being in a meeting room.
[0103]
As shown in FIGURE 6, there can be multiple detectors 102 within the
location outlined by the range of uncertainty 106. The location data from the
multiple
detectors 102 can be propagated into the syntaxes of the Location Types of
multiple
interaction spaces instantiating multiple Location Type Policies 112 and
Location Type
28
CA 02710643 2010-07-20
,
Data 114. In essence, the multiple detectors 102 can each provide location
lists for a
single person and these lists can be in multiple Location Types.
[0104]
Ambiguities can be resolved through the Location Selector 702 shown
within
FIGURE 6.
Generally, the confidence determinations in each Location Type can
provide a basis for preferring one over another. For example, a location can
be
preferred if it has the highest confidence in the Location Type Subtype of the
smallest
extent.
[0105]
In other embodiments, applications using the information can each have
their
own need for location determinations. Often, it can be of more utility to
provide aspects
of the Location Selector 702 within the application. In one example, a person
can have
policies that can operate differently if they are in the office or at home.
[0106]
In typical embodiments of the present application, the Location
Selector 702
can provide an application protocol interface (API) so that external
applications can
request location data of a certain Location Type and Subtype. In one
illustration, an
application can request location data of a certain Subtype or from a certain
detector 102
or class of detectors 102. This can be provided with an indication of
degradation in
either the clock or the degraded confidence determination. The application can
then
use its own way to select the most suitable location.
[0107]
FIGURE 7 is a flow chart providing an illustrative process for
approximating a
location of a person based on the multiple detectors 102 in accordance with
one aspect
of the present application. The process can begin at block 700. At block 702,
the
system 100 can assign precision values for each of the locations. The
precision values
can be associated with the level of accuracy required from a detector 102 to
detect a
person within that particular location. For example, a room location can have
a higher
29
CA 02710643 2010-07-20
,
precision value than a building.
[0108] At block 704, location detection data is received from detectors
102, and in
this embodiment, several detectors 102. The precision for the detectors 102 is
then
determined from the location data received from the detectors 102 at block
706.
Continuing with the examples provided above, a WiFi detector 102 can have a
very low
level of precision meaning that the accuracy of the WiFi detector 102 would be
able to
locate a person within a building and not within a room. On the other hand, a
GPS
detector 102 could have a high level of precision pinpointing a person within
a specific
room and floor.
[0109] At block 708, the system 100 can provide a location based on the
best
determined precision and assigned precision values for the location. Matching
the best
accuracy from the detectors 102 to the location with the highest precision
level, the
system 100 can determine where the person is based on the detector 102 having
the
best accuracy.
[0110] At decision block 710, system 100 can determine whether there is a
change
in location data. This can occur when the "best" detector 102 described above
can no
longer locate the person. In the alternative, a new detector 102 could have
detected the
location of the person within its range. Typically, the system 100 can
update its
information if any new location data is received. If there has been a change
in location
data, the processes return to block 706. Otherwise, the processes end at block
712.
[0111] Applications
[0112] FIGURE 8 provides exemplary applications 802 that can use
information from
the Location Selector 702 in accordance with one aspect of the present
application. In
typical embodiments, the applications 802 can utilize degraded confidence
declarations.
CA 02710643 2010-07-20
,
,
In some embodiments, policies could be triggered if a person's location
confidence
determination is below a certain threshold level. The system 100 can provide a
stand
alone web service or something similar through a LAN or wider network. It can
also be
closely integrated into larger applications 802.
[0113] The location data can be maintained in shared memory 110 and
made
available through an API for use by other applications 802. The service can be
provided on a local network or made available across the Internet. It can
function as a
web service that makes itself and its location data available on demand to
other
applications 802. The location service can also be integrated directly into a
larger
application 802.
[0114] As shown within FIGURE 8, the applications 802, can include,
but is not
limited to, to two basic types of applications: a location display 804 and a
location policy
806. The location display 804 can indicate an ambiguous user location with the
associated confidence declaration. It is known to one skilled in the relevant
art to show
a person's location on a plan. To show uncertainty, a person's location could
be shown
by the shading of the rooms or other locations that they could possibly be in.
The
uncertainty could be indicated by the hue and/or intensity of the color used
for shading.
[0115] Other applications 802 can include location policies 806 to
provide for
behavior. The uncertainty found for a person's location can be used as an
indication to
these policies. Some behaviors could be taken if there is a high degree of
confidence in
the person's location while others can require only a low degree. A policy
that turns on
the office lights when a person in their office's vicinity uses only a low
confidence in
location determination. Policies that can change the person's call forwarding
sensing
can result in lost calls. Therefore these use a significantly higher degree of
confidence.
31
CA 02710643 2010-07-20
The use of confidence thus facilitates the acceptance of such policies since
it allows
them to be tuned to the implications of their activity.
[0116] Typically, policies using location can be of two types. One is a
policy that can
control a behavior i.e. forward a user's call to their current location. The
other can be
meta-policies that control the behavior of other policies. For example, a meta-
policy
could indicate that a person's wireless telephone should not be rung if there
is likely or a
greater confidence that they are in a meeting room.
[0117] The location policies 806 should not be construed as limiting for a
single
person, but instead can incorporate many people. Applications 802 could also
combine
location data for multiple people. This for example could be used to detect
groups of
people. In a similar way, the policies could use data from other services. For
example,
if a group of people are detected in a meeting room, their calendars could be
consulted
to determine if this is a scheduled meeting. Data about the purpose and length
of the
meeting could be used to control other communication and collaboration
features. It
could be used by a presence and availability service to determine that a
person is at a
meeting and to determine that they will not be available for the duration of
the meeting.
[0118] Location Management and Creation
[0119] Previously, Location Types were provided to illustrate various ways
in which
humans could interact with each other. Through these Location Types, locations
were =
not limited to purely a physical concept, but could be pertinent to various
forms of
human collaboration and communication. Each Location Type could be generally
expressed in a specific syntax which was in a particular form of human
interaction. For
example, the Political/Physical Location Type, Enterprise Location Type, and
User
Location Type, provided above, each had features unique to their own form of
human
32
CA 02710643 2010-07-20
interaction.
[0120] As will be shown below, and within the scope of the current
application,
Location Types can be converted from one Location Type to another by means of
semantics that can be cast in the form of parameterizations, which was
described above
as Location Type Policies 112. These Location Type Policies 112 can make use
of
location data that is particular to a user, which can be within an entity
termed Location
Type Data 114. Often the burden of maintaining the Location Type Policies 112
and
Location Type Data 114 can overwhelm users as well as information technology
specialists within network management departments. As described herein, the
present
application provides techniques whereby both user's and information technology
specialists performing system management tasks with little to no training can
assume
the creation and management task of this information either automatically or
personally.
Furthermore, embodiments are presented that describe how the current location
information described above can be harnessed and how a user or system manager
can
define both Location Type Policies 112 and Location Type Data 114 to
personalize the
system and method.
[0121] Location Type Syntax
[0122] The creation and management system and method described herein can
be
understood by examining techniques for propagating location information from
one
Location Type to another. Returning to FIGURE 2, and by way of example, a user
202
can be detected using WiFi 102. As a result of its accuracy, the WiFi 102 can
place the
user in one of six rooms or within a hallway of the building 200. The user's
Physical/Political Location Type can include a list of seven possible
locations with
confidence declarations on each of the constituent sub-types in each location.
The
33
CA 02710643 2010-07-20
,
Physical/Political Location Type for the user 202, in one embodiment, can
include the
following:
<Political/Physical>
<<Country>><<United States>><<Confidence>><<Certain>>
<<City>><<New York City <<Confidence>><<Certain>>
District>><<Midtown>><<Confidence>><<Certain>>
Street>><<350 Fifth Avenue>><<Confidence>><<Certain>>
Building>><<Empire State Building>><<Confidence>><<Certain>>
Floor 56th Confidence Certain>>
<<Room>><<56123>><<Confidence>><<Possible>>
[0123]
Using the Physical/Political Location Type, a new Location Type can be
generated, for example, a User/Social Location Type. As depicted in FIGURE 9,
the
Source Location Type 902 can be combined with personal data 908 through
policies
906 represented by the ampersand (&) to generate a Destination Location Type
904.
While the Physical/Political Location Type can be used for certain purposes,
often the
user 202 can tune their specific Location Type Policies 112 and Location Type
Data 114
to meet their needs or requirements by using another Location Type. For
example,
users 202 can often trigger policies dependent on which office they are in
e.g., whether
the user 202 is in their own office or a colleague's. For purposes of
illustration, the
Physical/Political Location Type can be converted into a User/Social Location
Type
provided by the following syntax:
<User/Social>
Venue
Building
34
CA 02710643 2010-07-20
Office>>
[0124] Using the personal data 908 and policies 906 described above, the
subtypes
of the User/Social Location Type can be filled. The subtypes can include, but
are not
limited to venue, building, and office. Venue can take the values of unknown,
work, and
home. The subtype building, in typical embodiments, can indicate functions
within the
organization that are predominant within a particular location. For example,
the building
subtype can include unknown, billing office, accounts, etc. The subtype office
can refer
to personnel relationships. For example, the subtype office can include
unknown,
colleague's office, own office, boss' office, meeting room, etc. One
instantiation of the
User/Social Location Type can be:
<User/Social>
Venue Work
<<Building>><<Billing Office>>
<<Office>><<Colleague's Office>>
[0125] Location information expressed in User/Social Location Types can be
amenable to control and managing behavior that is applicable to user
collaboration and
communication. For example, private branch exchange (PBX) communications can
be
quite different if the user is in a colleague's office as opposed to a boss'
office. Thus,
these policies can be used, in one example, to enable and disable PBX
features.
[0126] Parameterizations
[0127] To convert the Source Location Type 902 to the Destination Location
Type
904, the ampersand (&) represents a group of policies 906 that can be used to
parameterize values. In further details, FIGURE 10 depicts exemplary direct
and
indirect parameterizations between Location Types in accordance with one
aspect of
CA 02710643 2010-07-20
,
the present application. Generally speaking, the group of policies 906 can
convert
values in the subtypes of the Source Location Type 902 to create subtypes in
the
Destination Location Type 904.
[0128] Direct parameterizations are components within the policies 906
themselves.
Often this involves matching or linking subtypes from the Source Location Type
902 to
subtypes of the Destination Location Type 904. As shown in FIGURE 10, the
upper two
arrows pointing to the Destination Location Type 904 indicate direct
parameterizations,
the arrows originating from the Source Location Type 902 with the subtypes of
the
Source Location Type 902 converted through the group of policies 906.
[0129] With specific reference to FIGURE 10, direct parameterizations can
be used
to fill in the venue subtype and the building subtype of the Destination
User/Social
Location Type 904 with information from the subtypes of the Source
Physical/Political
Location Type 902. As shown, the system and method can take the building and
floor
subtypes of the Source Physical/Political Location Type 902 and convert those
values to
the venue subtype within the Destination User/Social Location Type 904 using
the
group of policies 906. This subtype value can take on the value of work.
[0130] In addition, and continuing with the previous embodiment, the room
subtype
within the Source Physical/Political Location Type 902 can be used to directly
parameterize the room subtype within the Destination User/Social Location Type
904
using the group of polices 906. As shown, the value of the room subtype of the
Destination User/Social Location Type 904 can be a colleague's office. One
skilled in
the relevant art will appreciate that fewer or more subtypes from the Source
Physical/Political Location Type 902 can be used in each of those conversion
provided
above.
36
CA 02710643 2010-07-20
[0131] The system and method can also provide for indirect
parameterizations.
These parameterizations can typically be determined dynamically when the group
of
polices 906 are triggered. In one embodiment, a query can be sent to a shared
memory
to determine an appropriate value. The query can be composed of elements that
are
inherent to the policy 906 plus data that has been extracted from the Source
Location
Type 902.
[0132] Continuing the previous illustration shown in FIGURE 10, the room
subtype of
the Destination User/Social Location Type 904 can be indirectly parameterized.
Using
the Source Physical/Political Location Type 902, the group of policies 906,
and personal
data 908, indirect parameterizations can be made. In relation to the
illustrations
provided above, the personal data 908 can include a room reference to a
specific
person. The personal data 908 can show that room 56123 taken from the Source
Physical/Political Location Type 902 can be equivalent to the colleague's
office in the
room subtype of the Destination User/Social Location Type 904.
[0133] As described above, a query can be used for indirect
parameterizations.
FIGURE 11 represents a typical query structure 1100 for providing relational
information
in accordance with one aspect of the present application. The query, in one
embodiment, uses the group of policies 906 to determine relationships between
the
location information in the Source Location Type 902 and the information that
is
converted to the Destination Location Type 904. The policy 906 can be
generally
broken into criteria 1102 and a parameter 1104, which are described below.
[0134] To retrieve relationships, the personal data 908 includes a number
of
relational tables 1106. The criteria 1102 and the parameter 1104 within the
policy 906
can identify which of the relational tables 1106 is to be accessed. The
criteria 1102 can
37
CA 02710643 2010-07-20
,
,
point to a specific relational table 1106, while the parameter 1104 can
identify the
relation that is to be determined or verified within the tables 1106. In the
previous
illustrative embodiment, the relational tables 1106 can relate to the role of
individual
offices to the user 202. The parameter 1104 can identify the specific office,
which as
shown above, can be a colleague's office. The relations in the specified
tables 1106 are
therefore between the available offices designated by office number and a
user's role.
[0135] As shown above, the use of direct parameterizations and
indirect
parameterizations can allow policies to be made specific to individual users
202. This
can provide an opportunity to implement structure to the policies 906. This
structure
makes the system amenable to solutions to the management problems of
parameterizing a system to an individual user or users previously described.
As shown
in FIGURE 12, a block diagram depicting policies 906 can be applied to
multiple users
202 in accordance with one aspect of the present application. These policies
906 can
be shown as the larger block. The policy system can include policies and
personal data
from each user 202.
[0136] Provided within FIGURE 12, a set of generic policies 906 can
be created. For
example, policies 906 that relate to offices in various locations used by the
Enterprise
Location Type can be created. These policies 906 can be generic and can have
placeholders for personal data 908 so that they can be parameterized for
individual
users 202.
[0137] Tools
[0138] The structure provided by the use of the generic policies and
parameterizations allow for the creation of various applications, in the form
of tools.
Automated tools can use existing information within company databases to
create and
38
CA 02710643 2010-07-20
manage standard user locations. Personal tools can be provided so that a user
202 can
personally manage their own locations. The automated or personal tools can
take the
form of an entirely hardware embodiment, an entirely software embodiment, or
an
embodiment containing both hardware and software elements. In one embodiment,
the
system is implemented in software, which includes but is not limited to
firmware,
resident software, microcode, etc.
[0139] Automated Tools
[0140] FIGURE 13 provides an exemplary automated tool 1300 for the creation
and
management of policies 906 in accordance with one aspect of the present
application.
The automated tool 1300 can include a company database 1302, an agent 1310,
and
personal data 908. The company database 1302 can include, but is not limited
to, an
organization chart 1304, a personnel file 1306, and a contact list 1308. The
agent 1310
can provide an interface between the data stored in the company database 1302
and
the personal data 908. In addition, the agent 1310 can include a variety of
programs
that can utilize the structuring of the database 1302 and the policies 906
within the
personal data 908. In some embodiments, the agent 1310 can be programmed to
access external databases on the broader Internet. For example, the agent 1310
can
access a geographical information system (GIS) 1310 over the Internet. These
external
databases can be commercial or non-commercial.
[0141] In operation, and in accordance with one aspect of the present
application,
the agent 1310 can use a company organization chart 1304 provided within the
company database 1302 to determine values for the Destination Location Type
904.
Typically, user relationships can be defined within an organization chart
1304. Social
relationships, such as a colleague's office, boss' office, etc., can be used
to determine
39
CA 02710643 2010-07-20
=
values for the Destination Location Type 904 i.e. the User/Social Location
Type. From
there, the agent 1310 can link a User/Social Location Type to an Enterprise
Location
Type or other Location Type.
[0142] As recited above, the Enterprise Location Type can include
premises,
campus, building, and room subtypes. Of particular interest is the room
subtype of the
Enterprise Location Type. The room subtype can be indirectly parameterized and
linked to unknown in the relevant table 1106 of the personal data 908. The
agent 1310,
using the organization chart 1304, can link the offices to the appropriate
subtype in the
user's personal data 908. For example, the organization chart 1304 can
indicate a
user's direct manager and other supervisory personnel. A personal data
relation for
their office can be created indicating the boss's office relationship.
Similarly, the offices
of personnel in the same and closely related departments can be given the
status of a
colleague's office.
[0143] In another aspect of the present application, the automated
tool 1300 can be
used for direct parameterizations. In one example, a user's home address can
typically
be obtained by the agent 1310 from their personnel file 1306 on the company
database
1302. This address can be used in a query on the Internet or private GIS 1312.
The
GIS 1312 can return the physical geographic coordinates of the location in
terms of
latitude and longitude. Latitude and longitude can be in the form of the
location data
that is typically provided by a GPS system. Policies 906 can be provided that
link the
home location from raw data to the Physical Location Type and subsequently the
Enterprise Location Type or the User/Social Location Type. The venue subtype
in the
User Location Type can be provided with the value of home.
[0144] In another aspect, the automated tool 1300 can use customer
relationship
CA 02710643 2010-07-20
,
management (CRM) data typically located within the company database 1302. This
data can contain a contact list 1308, which can include the addresses of the
user
contacts. The agent 1310 can relate the customer addresses to longitude and
latitude.
Policies can allow their propagation from raw data to the Physical Location
Type and
subsequently to an Enterprise Location Type. Location sensitive applications
can use
the CRM data.
[0145] Personal Tools
[0146] In addition to the automated tools 1300 provided above, the
system and
method of the present application can provide a personal tool 1400 for
interfacing
policies 906 as depicted in FIGURE 14. As shown, the personal tool 1400 can be
located on the location device 104 which can be wirelessly connected to the
detector
102. The location device 104 can implement the personal tool 1400 through the
agent
1310. The location device 104 can be coupled to a database 1402. Coupled to
the
agent 1310 can be the GIS 1312 and the personal data 908. The personal tool
1400
can enable users to manage and personalize their own policies 906.
[0147] The agent 1310 can provide access to the policies 906. The
agent 1310 of
the structure can be allocated for the sole use of a single user or be
assigned to many
users. The agent 1310 can act as the interface between personal policy
management
tools. In doing so, it can provide the benefit of a standard interface to the
policy
databases, handle issues of security including user and policy update
validation, and so
forth. In some embodiments, the agent 1310 can be removed from the structure
and
the tools can have direct access to the policies 906. However, the ability of
the agent
1310 to supply standard interfaces and supply security capabilities allows for
system
scalability.
41
CA 02710643 2010-07-20
[0148] FIGURE 15 is a representative graphical user interface 1500 shown
for
illustrating behavior that can be provided by the exemplary personal tool 1400
in
accordance with one aspect of the present application. The graphical user
interface
1500 can be implemented on a networked device. The networked device can be,
but is
not limited to, a personal computer, a personal digital assistant, a cell
phone, and a thin
client terminal on a shared server. Generally, the device can be wireless and
can be
connected to a network. The network can include a local area network (LAN),
wide
area network (WAN), personal area network (PAN), campus area network (CAN),
metropolitan area network (MAN), or global area network (GAN).
[0149] Described below, there are three features that can be provided by
the
personal tool 1400. These features are for illustrating exemplary concepts and
can
include database updates, personal updates, and automatic location tracking
and
creation. Nonetheless, these disclosed features should not be construed as
limiting the
scope of the present application, but instead be taken as typical embodiments
of the
present application.
[0150] Database Update
[0151] As described above, personal data 908 can be obtained from company
databases 1302. Useful information can also be obtained from databases that
are of
primary interest to a single user. In one example, users 202 are commonly
provided
with CRM tools to enable their work. In another example, a user 202 can be
given a
tool by which they can manage their personal tombstone information for company
records. The user 202 can be given a tool to record their home address for tax
benefit
purposes along with dependent and other private information.
[0152] Personal Updates
42
CA 02710643 2010-07-20
[0153] The automated tool 1300 can create User Location Types from
organization
charts 1304. However, there can be occasions when a user 202 can update an
automated association, provide a new association, or enter a new location, for
example,
the case in which a user 202 wishes to add an additional employee as a
colleague or
when a user 202 wishes to provide a location association for a new physical
address.
[0154] On the graphical user interface 1500, an input/output area can be
provided
that can allow a user to enter in their physical location 1504. In one
example, a physical
location of an office in the Empire State Building 1502 is provided. This
physical
location can be propagated by the agent 1312 through the location policy
system to
create the User/Social Location Type equivalence which can be displayed in the
user
input/output area 1506.
[0155] Generally, at least one Location Type equivalence can be converted
from the
Physical/Political Location Type. Multiple locations can be easily handled
using multiple
Location Types on the graphical user interface 1500. The user 202 can then be
given
the capability of accessing and making changes to each of the Location Types.
[0156] In one example, if a User/Social Location Type is found, it can be
presented
in the User/Social Location Type input/output area 1506. In the case in which
no
User/Social Location Type is found, then the User/Social Location Type
input/output
area 1506 can be given an unknown value in each subtype. The user 202 can then
be
given the ability to modify the values in each of the subtypes. As shown in
FIGURE 15,
the user can be supplied with three buttons to indicate how the new data is
intended to
modify the location database. These buttons can include, but are not limited
to, remove
1508, replace 1510, and add 1512. The user 202 can update the databases in the
manner indicated by each button.
43
CA 02710643 2010-07-20
,
,
[0157]
In operation, the user 202 can modify the databases to handle multiple
locations.
To do so, the user can update the appropriate subtypes in the
Physical/Political Location Type input/output area 1504. For example, the user
can
update the floor or office number. In typical embodiments, the updating data
can be
facilitated by the display of a floor map 1514. The location can be indicated
by a user
symbol 1516 as illustrated. One skilled in the relevant art will appreciate
that there are
numerous types of ways to indicate that the user 202 is within a building.
[0158]
Continuing with the floor map 1514 provided above, the user 202 can be
given the ability to select a physical location by clicking or selecting the
appropriate area
on the floor map 1514. This can result in both the Physical/Political Location
Type
input/output area 1504 and User/Social input/output area 1506 being updated
with the
current location data. The user 202 can then choose to update the location
data using
the provided buttons.
[0159] Automatic Location Tracking and Creation
[0160]
In some embodiments, the graphical user interface 1500 of FIGURE 15
can
include a track button 1518 and specify button 1520. When the specify button
1520 is
selected, the system and method can be used in the personal update mode
described
above. Enabling the track button 1518 can provide another mode of operation.
In this
mode, GPS data can be used to track the user's location. The GPS data can be
acquired by the user's portable device.
It can then be propagated into a
Physical/Political Location Type by use of a GIS 1312. This can be
accomplished by
the agent 1312 forwarding GPS data from the personal device to a GIS 1312.
Alternatively, this could be accomplished by the personal device contacting a
GIS 1312
itself.
44
CA 02710643 2014-05-16
[0161] The
GIS 1312 can return parameters of the physical location which can be
transformed into Physical/Political Location Type by either the personal
device or the
agent 1312. The information can then be displayed within the user input/output
area
1504.
[01621
With the physical location being tracked, the operations can take place as
described above. The user can fill in portions of the Physical/Political
Location Type
that are not supplied by the GPS service. This information can be propagated
into a
User/Social Location Type and the user can be given the capability of
modifying or
otherwise editing the Location Type as described above.
10163]
While a specific graphical user interface 1500 has been described above for
the personal management of locations, one skilled in the relevant art will
appreciate that
there are many types of interfaces that can be provided and that are within
the scope of
the present application. Other interfaces can be of quite specific
application. For
example, there can be specific controls to indicate that a location determined
from GPS
information is of a specific type. A hard or soft key on a personal device can
be used to
indicate whether the current location is at a user's home or work location.
Other
location types such as CRM data can use this technique as well.
[0164] The
foregoing description is provided to enable any person skilled in the
relevant art to practice the various embodiments described herein.
Various
modifications to these embodiments will be readily apparent to those skilled
in the
relevant art, and generic principles defined herein can be applied to other
embodiments.
Thus, the claims are not intended to be limited to the embodiments shown and
described herein, but are to be accorded the full scope consistent with the
language of
the claims. Moreover, nothing disclosed herein is intended to be dedicated to
the public
CA 02710643 2014-05-16
regardless of whether such disclosure is explicitly recited in the claims.
46
