U.S. patent application number 10/503348 was filed with the patent office on 2005-10-06 for method of accessing the presence imformation on several entities.
Invention is credited to Butler, Dominic, Karlsson, Petter.
Application Number | 20050221807 10/503348 |
Document ID | / |
Family ID | 9930226 |
Filed Date | 2005-10-06 |
United States Patent
Application |
20050221807 |
Kind Code |
A1 |
Karlsson, Petter ; et
al. |
October 6, 2005 |
Method of accessing the presence imformation on several
entities
Abstract
The method allows a user to define groups of entities that will
be queried automatically for Presence information by his wireless
information device. The user, once he has selected the group to be
queried, need do no more than select at one time a `Pinging`
function using an on-screen dialog or other menu, which initiates
the automatic querying. There is no need to manually query each
member of the group for its Presence information.
Inventors: |
Karlsson, Petter; (London,
GB) ; Butler, Dominic; (London, GB) |
Correspondence
Address: |
SYNNESTVEDT LECHNER & WOODBRIDGE LLP
P O BOX 592
PRINCETON
NJ
08542-0592
US
|
Family ID: |
9930226 |
Appl. No.: |
10/503348 |
Filed: |
May 13, 2005 |
PCT Filed: |
February 3, 2003 |
PCT NO: |
PCT/GB03/00422 |
Current U.S.
Class: |
455/418 ;
455/419 |
Current CPC
Class: |
H04M 3/42 20130101; H04W
48/16 20130101; H04M 3/4938 20130101; H04W 48/08 20130101; H04M
3/42093 20130101; H04L 67/24 20130101; H04M 3/42365 20130101; H04W
8/24 20130101 |
Class at
Publication: |
455/418 ;
455/419 |
International
Class: |
H04M 003/00 |
Foreign Application Data
Date |
Code |
Application Number |
Feb 1, 2002 |
GB |
0202370.3 |
Claims
1. A method of enabling a wireless information device to access
Presence information of several entities, comprising the following
steps: (a) storing Presence information for several entities at one
or more data stores and making that information accessible; (b)
automatically sending, from the or each data store to the wireless
information device, Presence information for entities which meet or
match pre-defined Presence criteria, the criteria being defined or
selected by a user of the wireless information device by that user
selecting pre-defined Presence criteria displayed in one or more
menu lists shown on the device and that relate to Presence criteria
other than or in addition to physical or logical location, the
criteria potentially covering several such entities, and the
sending of the information from the or each data store to the
wireless information device occurring not as a result of any change
in the physical or logical location of the entities but instead
directly in response to the user selecting an option displayed on
the device that initiates a search for all entities that meet or
match the pre-defined Presence criteria at the or each data
store.
2. The method of claim 1 in which the menu list is hierarchical and
displays at one level a menu list comprising: (a) an option to
display criteria based on contacts; and (b) another option to
display criteria based on moods and/or activities; and displays at
a lower level the menu lists with the predefined user selectable
Presence criteria.
3. The method of claim 2 in which at least one of the criteria
defined or selected by the user is that the entities must be a
member of a pre-defined category of contacts of the user, each
category being a group category that is potentially populated with
several entities.
4. The method of claim 1 in which the criteria to be displayed in
one or more menu lists are user definable to enable new criteria to
be created and included in the menu lists.
5. The method of claim 1 in which a group of several, linked
criteria can be stored as a profile for future re-use.
6. The method of claim 1 in which the criteria are displayed within
a contacts or messaging application.
7. The method of claim 1 in which, in addition to selecting from
the menu lists, a user can enter free scripted queries that are
interpreted by a search engine using AI.
8. The method of claim 1 in which the step of storing Presence
information takes place at a server based database, programmed to
automatically respond when polled or requested by the wireless
information device.
9. The method of claim 1 in which the step of storing Presence
information takes places on remote wireless information devices
controlled by the owners of that Presence information and those
remote devices are programmed to automatically respond when polled
or requested by the wireless information device of the user.
10. The method of claim 1 in which the identity of all users
requesting or accessing Presence information is logged and
automatically sent to a wireless information device controlled by
the owner of that Presence information.
11. The method of claim 1 comprising the step of displaying on the
wireless information device the names of entities that meet the
criteria.
12. The method of claim 10 comprising the step of displaying, on
the wireless information device, available communication options
between the device and the entities that satisfy the criteria.
13. A wireless information device programmed to automatically
request Presence information for several entities which meet or
match pre-defined Presence criteria, the criteria being defined or
selected by a user of the wireless information device by that user
selecting pre-defined Presence criteria displayed in menu lists
shown on the device and that relate to Presence criteria other than
or in addition to physical or logical location, the automatic
requesting occurring not as a result of any change in the physical
or logical location of the entities but instead directly in
response to the user selecting an option displayed on the device
that initiates a search for all entities that meet or match the
pre-defined Presence criteria at the or each data store.
14. The wireless information device of claim 13 in which the menu
list is hierarchical and displays at one level a menu list
comprising: (a) an option to display criteria based on contacts;
and (b) another option to display criteria based on moods and/or
activities; and displays at a lower level the menu lists with the
predefined user selectable Presence criteria.
15. The wireless information device of claim 13 which requires that
at least some of the criteria defined or selected by the user are
that the entities must be a member of a pre-defined category of
contacts of the user, each category being a group category that is
potentially populated with one or more entities.
16. The wireless information device of claim 13 in which the
criteria displayed in one or more menu lists are user definable to
enable new criteria to be created and included in the menu
lists.
17. The wireless information device of claim 13 in which a group of
several, linked criteria can be stored as a profile for future
re-use.
18. The wireless information device of claim 13 in which the
criteria are displayed within a contacts or messaging
application
19. The wireless information device of claim 13 in which, in
addition to selecting from the menu lists, a user can enter free
scripted queries that are interpreted by a search engine using
AI.
20. The wireless information device of claim 13 adapted to: (a)
communicate with a server based database which stores Presence
information for several entities; (b) poll or request Presence
information from the server; (c) display Presence information
relating to one or more entities which has been sent to the device
from the server in response to a request from the device.
21. The wireless information device of claim 13 adapted to: (a)
communicate with several other wireless information devices, each
storing Presence information; (b) poll or request Presence
information from each of the other wireless information devices;
(c) receive and display that Presence information.
22. The wireless information device of claim 13 programmed to
display the Presence information of one or more entities meeting
the criteria, together with a user selectable option to contact the
or each entity using voice or message based communication.
23. The wireless information device of claim 13 programmed to
receive a response from the data store and, using that response, to
itself determine what entities satisfy the criteria defined or
selected by the user.
24. The wireless information device of claim 13 in which the store
determines whether a given entity satisfies the criteria.
25. The wireless information device of claim 13 in which the
criteria can be saved and re-used at a later time.
26. Computer software which, when running on a wireless information
device, causes the device to display: (a) a menu list of
pre-defined Presence criteria that relate to Presence criteria
other than or in addition to physical or logical location, the
criteria potentially covering several entities; b) an option to
initiate a search for all entities that meet or match pre-defined
Presence criteria selected from the menu list.
27. The computer software of claim 25, which, when running on the
wireless information device, causes the device to operate as a
device claimed in claim 13.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] This invention relates to a method of enabling a wireless
information device to access the Presence information of several
entities. `Presence` information refers to private user data which
gives information and hints about the current state of a user of a
wireless information device, including location, availability and
mood. The term `wireless information device` used in this patent
specification should be expansively construed to cover any kind of
device with one or two way communications capabilities and includes
without limitation radio telephones, smart phones, communicators,
personal computers, computers and application specific devices. It
includes devices able to communicate in any manner over any kind of
network, such as GSM or UMTS mobile radio, Bluetooth.TM., Internet
etc.
[0003] 2. Description of the Prior Art
[0004] Current generation wired and wireless telephones can
indicate to a caller the status of a call recipient in only crude
and potentially ambiguous terms: for example, when a caller makes a
voice call, he or she might receive one of five different
responses: (a) the desired call recipient answers; (b) there is no
answer; (c) there is an engaged tone; (d) the call gets put through
to a pre-recorded voice mail message or (e) the call gets diverted
to someone else. If the intended call recipient does not actually
answer the call, then the caller has no idea why the call was not
answered: for example, is the intended recipient in fact there but
too busy to answer? Could a different number have been dialled to
connect successfully?
[0005] Conventional so-called `Presence` systems are the subject of
considerable interest at present and partly solve the above
problems. The intent of Presence systems is to show the status of
the prospective call recipient to a calling party ahead of the
caller making the call--for example, giving information about
whether the intended call recipient is busy, in a meeting,
contactable on a mobile phone or land line, giving hints about the
way the call recipient would prefer to be contacted (voice, SMS
etc). Reference may be made to RFC 2778 `A Model for Presence and
Instant Messaging` February 2000, The Internet Society.
[0006] Presence information will typically be stored on one or more
servers controlled by a wireless operator; people can post their
Presence information onto these servers directly from their own
wireless information devices; some kinds of Presence information
may also be determined automatically, such as the location of the
device. Someone seeking Presence information relating to (or
`owned`) by another can access these servers. Peer to peer variants
are also possible, with an individual storing his or her Presence
information on his or her own wireless information device, which
can give access to that information to other wireless information
device or servers that wish to pull down this information.
Reference may be made to PCT/GB01/03784 filed by the present
applicant, which describes a comprehensive Presence architecture
and is incorporated by reference into this disclosure. Further
reference may also be made to PCT/GB01/03804 again filed by Symbian
Limited, which discloses an extensible database architecture
suitable for the fast and efficient deployment of Presence related
systems and is again incorporated by reference into this
disclosure.
[0007] Presence information can potentially be very useful in
social situations, such as where an individual simply feels like
talking to a friend: he can then manually and sequentially query
the Presence information of his friends and avoid those who have
posted Presence information such as `In a meeting` or `Don't
Disturb`. Querying another's Presence information will typically be
done through a simple dialog screen, for example on the contacts
application running on the wireless information device of the above
individual, there could be a menu listing different communications
options that can be initiated when a particular person's contact
record is being viewed--e.g. `call` (to place a voice call to that
person); `message` (to write and send a SMS text message to that
person); and `Get Presence` (to obtain the Presence information of
that person). Using the `Get Presence` option separately for each
person in turn that he might like to talk to, he perhaps finds a
friend who has posted the Presence information `Bored` and he can
then initiate a voice call with that person. The process of
sequentially and manually checking Presence information is however
quite slow.
SUMMARY OF THE PRESENT INVENTION
[0008] In a first aspect of the present invention, there is a
method of enabling a wireless information device to access Presence
information of several entities, comprising the following
steps:
[0009] (a) storing Presence information for several entities at one
or more data stores and making that information accessible;
[0010] (b) automatically sending, from the or each data store to
the wireless information device, Presence information for entities
which meet criteria defined or selected by a user of the wireless
information device, the criteria potentially covering several such
entities, and the sending of the information occurring in response
to the user singly selecting an option displayed on the device.
[0011] Hence, users can automatically initiate a pull down of
Presence information from several entities through a single action,
as opposed to having to sequentially open the contact record for
each entity and select a `Get Presence` type option for each
entity. This is also different from automatically and instantly
pushing changed Presence information to all users in a pre-defined
group (e.g. pushing an entity's Presence information to all persons
listed as `friends` in that entity's contacts list, including all
changes to that Presence information), which is potentially far
more costly since it results in Presence data traffic that may be
superfluous.
[0012] The criteria defined or selected by the user may be that the
entities are a member of a pre-defined category of contacts of the
user, each category being populated with one or more entities. For
example, typical categories might include:
[0013] close family; extended family; close friends; football
friends; book club friends; clubbing friends; cinema friends;
shopping friends; class mates; work colleagues; work colleagues in
dept A; work colleagues in dept B with skills C etc. etc.
[0014] These criteria could be listed in a menu option on the
user's device (e.g. within the contacts or messaging application)
and also be user definable to enable new categories to be created
as needed. The device would automatically send, to the data store
storing Presence information for each entity satisfying the defined
criteria, a request to return the relevant Presence information.
This would happen on user initiation by, for example, the user
selecting the `Get Presence` option from a dialog box or other kind
of menu. Because that `Get Presence` selection is automatically
applied to all entities meeting the defined criteria, a user could
poll, for example, all members of the `class mates` category for
their Presence with just a single process, instead of having to
repeat that process for each individual class mate.
[0015] The criteria defined or selected by the user may be that the
Presence information itself meets criteria defined or selected by
the user. These criteria could again be listed within the contacts
or messaging application. For example, if the user wants to plan a
social engagement with a friend, the criteria might be to exclude
entities with Presence information for moods/activities including
`in meeting`, `at work`, `busy`, or to include only entities with
Presence information that include the `Free for lunch` status or
similar Presence information. This approach may require Presence
information to be selected from standard options used by all
entities, rather than for entities to be able to free script their
status. It might also be satisfied by a query engine using a degree
of AI, which could interpret free scripted status messages. The
Presence information sent to the requesting wireless information
device may be a simple answer (e.g. `yes` or `no`) to whether there
is a match to criteria sent by the device. Or it may be the
Presence information actually stored (e.g. in response to a query
"What is your mood", it would then be the Presence information
"Busy").
[0016] The Presence criteria defined or selected by the user may be
that the Presence information indicates that an entity is at or
within a predefined location.
[0017] In a second aspect, there is a wireless information device
programmed to automatically request Presence information for
several entities which meet criteria defined or selected by a user
of the wireless information device, the automatic requesting
occurring in response to the user singly selecting an option
displayed on the device.
[0018] A third aspect covers computer software which, when running
on a wireless information device, enables the device to
automatically request Presence information for several entities
which meet criteria defined or selected by a user of the wireless
information device, the automatic requesting occurring in response
to the user singly selecting an option displayed on the device.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] The invention will be described with reference to the
following Figures:
[0020] FIGS. 1-8 show a screen from a mobile telephone illustrating
the operation of the present invention;
[0021] FIG. 9 shows a high level architecture schematic for an
implementation of the present invention.
DETAILED DESCRIPTION
[0022] An implementation of the present invention is called
`Pinging` and runs on wireless information devices with the Symbian
OS from Symbian Limited of London, United Kingdom. The `Pinging`
function is implemented as an application or UI extension to an
existing application, such as a contacts or messaging application.
It allows a user to select criteria that define entities who will
be queried automatically for Presence information by his wireless
information device. The user, once he has defined the criteria
(e.g. selected a particular group to be queried, such as contacts
classed as `Friends` in his contacts/address book application) then
need do no more than select at one time a `Pinging` function using
an on-screen dialog or other menu, which initiates automatic
querying across all entities that meet the criteria. There is no
need to manually query each member classified as a `Friend` for its
Presence information.
[0023] The device can display in effect a series of different lists
with selectable items in each list; selecting an item in a list
activates that item as a query filter. One list might include all
of the available contact categories (close family; extended family;
close friends etc.). Another list might include the available
moods/activities (in meeting, at work, busy, free for lunch, want
to meet up etc.). Another list could include different Presence
location parameters referred to as "landmarks" (Home, work, school)
plus the option of opening a mapping application that would enable
the user to define a location or new landmark. The nature and
content of these lists could be altered and augmented to
accommodate the different and evolving Presence parameters that can
be queried against. In this way, a user could rapidly select the
filters to be applied to his Presence search enquiry--e.g. all
contacts who are `Friends` and have selected a `Let's Party` mood
for their Presence. This approach is shown in FIG. 1-8.
[0024] Referring to FIG. 1, the display screen of a wireless
information device is shown at 1. The Contacts application is open
and options for three possible communication processes are shown,
`Voice`, Text, and `Ping!` at 2. If the user selects the `Ping!`
option 2, then the FIG. 2 screen is generated. It shows three
different kinds of criteria or filters that can be applied:
`Contacts` 3, `Mood/activity` 4 and `Location` 5. The user has
selected the check box 6 for Contacts and also Mood/activity. This
causes the device to show, in FIG. 3, the two main ways of
selecting contacts: either by selecting them individually 7 (e.g.
scrolling through the contacts list and selecting the required
contacts one by one) or by selecting a group 8 into which
individual have previously been categorised by the user. The
`select Groups` option 8 is selected, leading to the FIG. 4
display, which shows the different kinds of Groups available in a
list 9: Friends, familiy, Work A, Clubbing, Class are featured. The
user selects Friends, which is hence highlighted at 10. The device
now displays, FIG. 5, the different mood/activity criteria
available in list 11: Work, Bored, Let's party, Let's lunch, Busy,
Shopping are shown in the list. The user selects `Let's party` 12,
shown highlighted. If the user had also selected the Location
pinging filter (FIG. 2), then a list of available location criteria
would then be displayed, FIG. 6: Home, work, School are listed in
list 13. Also, there is an option to open a mapping application 14
to enable the user to define geographically a location. Because the
user had in fact not selected the `location` Pinging filter, his
criteria selection is now complete and is confirmed in the screen
shown at FIG. 7, showing that Friends and Let's party are the live
filters 15. Critically, there is also displayed a single button
labelled `Ping!` 16. Selection of this button causes the device to
automatically establish what entities meet the two criteria of
being both in the `Friends` list of the user and also have
themselves posted a `Let's party` mood. It does this by sending a
Presence information request (detailed below) out to the repository
of the Presence information of all contacts who are listed as
`friends` in the user's contacts application. This may be a server
based database, programmed to automatically return Presence
information to the user's wireless information device (if suitably
authorised) when polled or requested by that device.
[0025] A peer to peer approach is also possible: the Presence data
is then not stored on a central database server and managed
centrally by the database server owner (e.g. network operator), but
is instead distributed across wireless information devices such
that the Presence information for any given user is stored on and
managed by software on that user's wireless information device. The
software on a device will handle Presence information requests from
other users, including filter against Presence related queries from
other devices, it will log Presence information requests, may be
programmed or otherwise configured by the user to deny/permit
requests from given users, will facilitate communication with the
entity that has requested Presence information and will generate
and display data Presence information requested by other devices.
Hence, in the above example, the request for Presence information
could be sent out directly to each remote wireless information
device controlled by each entity listed as a `friend`, with each
device programmed to automatically return Presence information back
to the requesting wireless information device when polled or
requested if it also matches the `Let's party` mood.
[0026] Hence, actual filtering against the `Let's party`
requirement can take place at the resource which stores the
Presence information (e.g. server or wireless information device of
the contact being polled), with that resource in effect performing
a match against the query represented in a structured query
language (e.g. does your Presence information include a `Lets
party` mood); a nil return would be sent to the requesting device
(or indeed other server) if there was no match. A `yes` return
would be sent if there was a match. Alternatively, a more general
query could be sent by the requesting device (e.g. `tell me all of
your Presence information that I am entitled to see`), with the
resource(s) storing the Presence information returning that
information and the requesting device itself performing the
necessary matching against the user defined criteria.
[0027] Finally, the Presence information for each entity satisfying
the criteria is automatically displayed against their contact
record in the contacts application. Alternatively, as shown in FIG.
8, a new table 17 can be generated within the contacts application
that lists all of the friends by name that meet the `Let's party`
mood. The user's device also displays a communication dialog window
18 that readily allows the user to select a person from the list
and initiate a voice or text communication with him or her. In FIG.
8, the name `Jim` is shown selected and highlighted: the user can
rapidly open up a voice channel or text him using the appropriate
options in box 18.
[0028] The end result will be that the user is given only the
Presence information that he or she is interested in reading. The
background process that delivers this may involve querying Presence
information of large numbers of entities. The user initiates this
by singly (i.e. once only) selecting an option displayed on the
device--e.g. after selecting the filters, he or she simply selects
a `Get Presence` or `Ping!` button (16 in FIG. 7) once only and
then, as a background process, Presence information is requested by
the device from all applicable entities, compared against the
necessary filter criteria and any relevant information displayed.
In the example illustrated, that is a list of all `friends` who are
in the `Let's party` mood. As FIG. 7 shows, the user has simply to
select the `Ping!` button 16 once to initiate the entire process
that leads to this.
[0029] Another alternative scenario is that a school child might be
interested in seeing the Presence of all class mates: he or she
simply selects `class` as a filter (see the options listed at 9 in
FIG. 4), selects the option `Ping!` function 16 and all of the
class mates' Presence information is returned for display on his
device.
[0030] A further useful feature would be to allow the user to set
up commonly-used filter "profiles" using the process described
above and then to save them for future use. Next time the user
wants to find his friends with mood "Let's Party", he need only
select the appropriate profile and press the Ping! button.
[0031] Because this system is potentially intrusive, it is sensible
to build in safeguards against inappropriate use. One safeguard is
that the identity of the user requesting access to an entity's
Presence information is logged and automatically sent to a wireless
information device controlled by that entity or used by that device
for display on that device. Logging can be on the data store that
stores the Presence information (e.g. a server or on a device
itself for a peer to peer approach); it provides an audit trail of
who has requested any individual's Presence information and will
act as a disincentive to inappropriately requesting someone else's
Presence information. In a typical implementation of the present
invention, Presence information is stored on server based databases
controlled by a wireless network operator; those servers can be
programmed to log all access requests to Presence information (e.g.
identity of person accessing the Presence information, the nature
of Presence information accessed, the time/date of access) and to
send that information to the relevant user's wireless information
device. That device is then programmed to display the fact that
Presence information has been requested or accessed and to give the
user the option of viewing the log. The server based databases may
be programmed to automatically deny access to Presence information
from pre-defined categories of entities (e.g. black-listed persons,
entities not listed in the user's contact list stored on the
database; commercial organisations etc.), so that it is useful to
be able to inform a user not only when Presence information has
been accessed, but also when it has been requested and denied.
[0032] Presence Architecture
[0033] The Presence system architecture will now be discussed in
overview. It is typically Client/Server: an Instant Messaging and
Presence (IMP) Server holds master copies of Presence information
and other `Personal Data`: Personal Data is non transient data
(unlike Presence information) which the user wishes to store in a
database that can be accessed within user defined access limits
(e.g. to defined classes of individuals etc.). Personal data could
include such things as: MP3 files; photos; credit card details;
date of birth and other auto from fill information; medical
records; Agenda; Public PGP key, etc. i.e. file, record and
transaction based shared content.
[0034] The server listens for client connections and communicates
directly with clients and other servers. The server also handles:
data storage, user authentication, directory lookups (e.g. LDAP)
and Rosters, etc. The server can log all requests for Presence
information (e.g. the name of the entity requesting that
information, the contact numbers, e-mails etc, the kind of Presence
information sought, the time/date of access, whether access was
successful or not etc.), perform filtering against structured
requests and can send required Presence information (which could be
a `yes` response, or the actual information stored, e.g. a defined
mood such as `Lets party`) that matches or satisfies the request
parameters back to the client device that requested it.
[0035] The client communicates with the IMP server, parses and
interprets well-formed XML packets and understands message data
types.
[0036] Returning to the overall architecture, each user is
associated with a single server which receives information for them
and from them. But in a typical network, there could be many IMP
servers provided by the same operator, with the servers
transferring messages and Presence information between themselves
and, with the appropriate interoperability standards in place (e.g.
SIMPLE), with other external IM and presence systems too. A
Client/Server protocol (preferably an open XML-based standard) is
employed for communications. This is used for client-server,
server-client and server-server communication (session initiation,
modification and termination). A server-to-server protocol may also
be used--SIP/SIMPLE for interoperability between heterogeneous
systems would be a natural design choice.
[0037] Data representation protocol: a fundamental requirement of
the architecture is that it must be extensible. As such, an open
XML-based standard protocol should be used for
packaging/transporting data (IM, Presence data and personal
information). The protocol should use XML namespaces to encapsulate
other kinds of data sent, allowing any client, server, transport,
or any component of the architecture to build custom applications
by including their own XML data within their namespace. SOAP may be
employed. Along with a flexible messaging and presence system, an
XML-based directory should be provided. As to account management,
the server by default will allow every user to have full control
over the creation of and management of their account. This includes
passwords, and all presence, personal data and messaging aspects.
Server administrators have full control over the rights allotted to
each account, and can remove or limit those at any time.
[0038] Pinging Architecture
[0039] FIG. 9 is a high level schematic of the overall Pinging
architecture: the `Pinging` function is implemented as an
application or UI extension to existing applications, such as
contacts or messaging `apps` 23 which can send the their Presence
related queries (e.g. "get Presence for Joe and Sally") to a
Presence Framework 19 on the client device. The Presence Framework
19 communicates via a local database plugin 21 with a local
Presence Data store 22. Presence Framework 19 communicates via
network plugin 20 over network 24 either directly to other client
devices 26, 27 (if a peer to peer Presence system is used) or with
a network Presence Data store 25 for a more conventional client
server model.
* * * * *