U.S. patent application number 13/313514 was filed with the patent office on 2012-03-29 for efficient transmission of presence update information to presence service clients.
This patent application is currently assigned to RESEARCH IN MOTION LIMITED. Invention is credited to H. K. Michael Hung, Gerhard Dietrich Klassen, Andreea Manolescu.
Application Number | 20120079016 13/313514 |
Document ID | / |
Family ID | 39707579 |
Filed Date | 2012-03-29 |
United States Patent
Application |
20120079016 |
Kind Code |
A1 |
Hung; H. K. Michael ; et
al. |
March 29, 2012 |
EFFICIENT TRANSMISSION OF PRESENCE UPDATE INFORMATION TO PRESENCE
SERVICE CLIENTS
Abstract
To promote efficient transmission of presence update information
to a presence service client associated or integrated with a
communication client such as an instant messaging (IM) client, a
separate computing device may be notified when the communication
client becomes dormant. The separate device may buffer presence
updates destined for the communication client, each presence update
containing information regarding availability of at least one of a
set of contacts for intercommunication via said communication
client. When the separate device learns that either the
communication client has ceased being dormant or that an event has
occurred which shall cause the communication client to cease being
dormant, the buffered presence updates may be sent to the presence
service client. Presence updates within the buffered set may be
reconciled to eliminate obsolete information. The result may be a
conservation of wireless connection bandwidth or reduction in
device power consumption.
Inventors: |
Hung; H. K. Michael;
(Toronto, CA) ; Manolescu; Andreea; (Toronto,
CA) ; Klassen; Gerhard Dietrich; (Waterloo,
CA) |
Assignee: |
RESEARCH IN MOTION LIMITED
Waterloo
CA
|
Family ID: |
39707579 |
Appl. No.: |
13/313514 |
Filed: |
December 7, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11677186 |
Feb 21, 2007 |
8095603 |
|
|
13313514 |
|
|
|
|
Current U.S.
Class: |
709/203 |
Current CPC
Class: |
H04L 67/24 20130101;
H04L 67/2838 20130101; H04L 67/04 20130101; H04L 51/04 20130101;
H04L 67/28 20130101 |
Class at
Publication: |
709/203 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A method performed by a server that is configured to wirelessly
transmit presence updates to a presence service client associated
with a communication client executing on a wireless communication
device, comprising: receiving an indication that the communication
client has become dormant; in response to receiving the indication,
buffering presence updates destined for the presence service
client, each presence update indicating availability of a contact
for communication with the communication client; receiving a
further indication that an event has occurred that will cause, but
has not yet caused, the communication client to cease being
dormant; and in response to receiving the further indication,
transmitting the buffered presence updates to the presence service
client.
2. The method of claim 1 wherein the indication is a communication
from the communication client.
3. The method of claim 1 wherein the communication client is an
instant messaging client.
4. The method of claim 1 wherein the further indication is based on
a condition that is known to the server before it is known to the
communication client.
5. The method of claim 4 wherein the condition comprises a
communication, other than a presence update, destined for the
communication client.
6. The method of claim 4 wherein the condition is that a contact of
interest of the communication client has logged into an instant
messaging service.
7. The method of claim 1 wherein the transmitting occurs despite
the server not having received an unhold message from the
communication client.
8. The method of claim 1 wherein the communication client becoming
dormant comprises presence information being undisplayable on a
screen of the communication device.
9. The method of claim 1 wherein the transmitting includes
reconciling the presence updates into a single presence update and
transmitting the single presence update.
10. A method performed by a server that is configured to wirelessly
transmit presence updates to a presence service client associated
with a communication client executing on a wireless communication
device, comprising: receiving an indication that the communication
client has become dormant; in response to receiving the indication,
buffering presence updates destined for the presence service
client, each presence update indicating availability of a contact
for communication with the communication client; receiving a
further indication that an event has occurred that will cause the
communication client to cease being dormant; and in response to
receiving the further indication, transmitting the buffered
presence updates to the presence service client, despite the server
not having received a notification from the communication client
that the communication client has ceased being dormant.
11. The method of claim 10 wherein the communication client is an
instant messaging client, and the indication is an instant message
from the communication client.
12. The method of claim 10 wherein the further indication is based
on a condition that is known to the server before it is known to
the communication client.
13. The method of claim 12 wherein the condition comprises a
communication, other than a presence update, destined for the
communication client.
14. The method of claim 12 wherein the condition is that a contact
of interest of the communication client has logged into an instant
messaging service.
15. The method of claim 10 wherein the communication client
becoming dormant comprises presence information being undisplayable
on a screen of the communication device.
16. The method of claim 10 wherein the transmitting includes
reconciling the presence updates into a single presence update and
transmitting the single presence update.
17. A method performed by a server that is configured to wirelessly
transmit presence updates to a presence service client associated
with a communication client executing on a wireless communication
device, comprising: receiving an indication that the communication
client has become dormant; in response to receiving the indication,
buffering presence updates destined for the presence service
client, each presence update indicating availability of a contact
for communication with the communication client; receiving a
further indication that an event has occurred that will cause the
communication client to cease being dormant; reconciling the
presence updates into a single presence update; and in response to
receiving the further indication, transmitting the single presence
update in place of the buffered presence updates.
18. The method of claim 17 wherein the reconciling includes
retaining only a most recent of the buffered updates.
19. The method of claim 17 wherein the communication client is an
instant messaging client, and the indication is an instant message
from the communication client.
20. The method of claim 17 wherein the communication client
becoming dormant comprises presence information being undisplayable
on a screen of the communication device.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This is a continuation of U.S. application Ser. No.
11/677186, filed Feb. 21, 2007, hereby incorporated herein by
reference.
FIELD OF TECHNOLOGY
[0002] The present disclosure pertains to presence services, and
more particularly to the efficient transmission of presence update
information to presence service clients.
BACKGROUND
[0003] Instant messaging ("IM") is a known form of substantially
real-time communication between two or more computing devices that
is often based on typed text. The text (and, more recently, other
types of data, such as electronic files, streaming content or even
voice) is conveyed between the computing devices over a network
such as the Internet. Each computing device executes an IM client
software application (sometimes referred to simply as an "IM
client") associated with an IM service. The IM service defines a
protocol for instant messaging which may be proprietary. Popular
instant messaging services on the public Internet currently include
.NET Messenger Service, AOL.RTM. Instant Messenger.TM. (AIM),
Excite.RTM. Pal, Gadu-Gadu, Google Talk.TM., iChat.RTM., ICQ.RTM.,
Jabber.RTM., Qnext.TM., QQ.RTM., Skype.RTM. and Yahoo!.RTM.
Messenger. Multi-protocol clients such as Gaim, Trillian.TM. and
Miranda may eliminate or reduce the need for separate client
software applications for different IM services. Popular enterprise
IM solutions include IBM Lotus Sametime.TM., Novell GroupWise.RTM.
and Microsoft.RTM. Office Live Communications Server.
[0004] Most if not all IM services have an associated presence
service. A presence service permits each user to see whether other
users in a user-specified set of contacts (commonly known as a
"contact list", "buddy list" or "friend list") are currently
on-line and available for exchanging instant messages. The
availability of each contact may be indicated by way of a presence
state indicator such as "available", "busy", "idle", "do not
disturb", or "out to lunch" for example, which is displayed by the
IM client. Presence information is updated by way of presence
updates, which are automatically sent to users who have elected to
receive them in respect of a specified set of contacts. A presence
service client that is associated with, and in many cases
integrated with, the IM client handles presence updates and
generally maintains presence state indicators for display to the
user, typically by way of the IM client user interface. Presence
service clients may also be used in association with other types of
communication clients, such as Voice over Internet Protocol (VoIP)
clients. When a contact's presence service client detects that the
availability of the contact has changed, it automatically reports
the changed availability to other users. This is typically done by
way of a central server, which in the case of an instant messaging
system is a central IM server. Specifically, the report regarding
changed status is sent to the central IM server, which in turn
reports the changed availability by way of presence updates that
are sent to all connected IM users who have elected to receive such
updates regarding that contact. A presence update is a
communication (e.g. a message) which provides an indication of the
current availability of the contact for communication (e.g. instant
messaging). Presence services and instant messaging are both
described in further detail in "RFC 2778--A Model for Presence and
Instant Messaging", which is available at www.ietf.org/rfc2778.txt
and is known to those of ordinary skill in the art.
[0005] In some cases, the computing device that executes the
presence service client is a wireless communication device. For
example, an apparatus and method for wireless instant messaging is
described in U.S. Patent Publication No. 2006/0142030 A1, which is
incorporated by reference hereinto. The IM client software
application executing at a wireless communication device may be
referred to as a "mobile IM client", and the associated presence
service client may be referred to as a "mobile presence service
client". Mobile presence service clients may receive presence
updates over a wireless connection. If the frequency and number of
presence updates is high, as may occur when the number of contacts
in the contact list of the wireless communication device user is
large, various problems may result. Firstly, a large portion of the
wireless connection bandwidth may be consumed by incoming presence
updates. Because many wireless service providers charge subscribers
based (at least in part) upon the amount of data received, the
receipt of frequent and numerous presence updates may
disadvantageously increase subscription costs. Secondly, receiving
and processing a large number of presence updates may consume a
significant amount of power at the wireless communication device,
which may in turn undesirably shorten battery life. This may be
especially true if each presence update causes the wireless
communication device to "awaken" from a power-saving mode and
remain in that awakened (non-power-saving) mode for some minimum
period of time. Thirdly, because some wireless providers or
wireless network types may deem each transmission of one or more
presence updates to constitute a "call", any call statistics that
are maintained for the device may be significantly skewed by the
transmission of frequent individual presence updates. Finally, the
frequent transmission of messages containing only one presence
update apiece may be inefficient because the overhead associated
with each message (e.g. generating, communicating and interpreting
header information such as checksums) may be unacceptably high.
These shortcomings may be endemic in presence services regardless
of whether they are associated with instant messaging or other
forms of communication (e.g. VoIP). A solution which mitigates or
obviates one or more of these shortcomings would be desirable.
BRIEF DESCRIPTION OF DRAWINGS
[0006] In the figures which illustrate example embodiments:
[0007] FIG. 1 is a schematic diagram of an IM system with an
associated presence service;
[0008] FIG. 2 is a schematic diagram of a wireless communication
device component of the IM system of FIG. 1;
[0009] FIG. 3 is a representation of a contact list associated with
an mobile IM client software application;
[0010] FIG. 4 is a flowchart illustrating operation a proxy IM
server software component of the IM system of FIG. 1;
[0011] FIG. 5 is a flowchart illustrating operation of a mobile IM
client software application component of the IM system of FIG.
1;
[0012] FIG. 6 is a state machine effected by the proxy IM server
software whose operation is illustrated in FIG. 4;
[0013] FIG. 7 is a state machine effected by the mobile IM client
software application whose operation is illustrated in FIG. 5;
[0014] FIGS. 8 and 9 illustrate the format of two types of messages
sent by the wireless communication device component of the IM
system of FIG. 1;
[0015] FIG. 10 is a schematic representation of a set of presence
updates buffered by a proxy IM server component of the IM system of
FIG. 1;
[0016] FIG. 11 is a schematic representation of the buffered set of
presence updates of FIG. 10 after they have been reconciled;
and
[0017] FIG. 12 illustrates a schematic diagram of an alternative IM
system.
DETAILED DESCRIPTION
[0018] In one aspect of the below described embodiment, there is
provided a computer-implemented method comprising: receiving an
indicator that a communication client executing at or comprising a
separate wireless communication device has become dormant;
responsive to said receiving, buffering a set of presence updates
destined for a presence service client associated with said
communication client, each presence update of said set containing
information regarding availability of at least one contact of a set
of contacts for intercommunication via said communication client;
receiving a further indicator indicating either that said
communication client has ceased being dormant or that an event has
occurred which shall cause said communication client to cease being
dormant; and responsive to said receiving of said further
indicator, sending said set of presence updates to said presence
service client via a wireless connection.
[0019] In another aspect of the below described embodiment, there
is provided a computing device comprising at least one processor
and memory in communication with said at least one processor, said
memory storing instructions which, when executed by said at least
one processor, adapt said computing device to: receive an indicator
that a communication client executing at or comprising a separate
wireless communication device has become dormant; responsive to the
receipt of said indicator, buffer a set of presence updates
destined for a presence service client associated with said
communication client, each presence update of said set containing
information regarding availability of at least one contact of a set
of contacts for intercommunication via said communication client;
receive a further indicator indicating either that said
communication client has ceased being dormant or that an event has
occurred which shall cause said communication client to cease being
dormant; and responsive to the receipt of said further indicator,
send said set of presence updates to said presence service client
via a wireless connection.
[0020] In yet another aspect of the below described embodiment,
there is provided a machine-readable medium storing instructions
which, when executed by at least one processor of a computing
device, adapt said computing device to: receive an indicator that a
communication client executing at or comprising a separate wireless
communication device has become dormant; responsive to the receipt
of said indicator, buffer a set of presence updates destined for a
presence service client associated with said communication client,
each presence update of said set containing information regarding
availability of at least one contact of a set of contacts for
intercommunication via said communication client; receive a further
indicator indicating either that said communication client has
ceased being dormant or that an event has occurred which shall
cause said communication client to cease being dormant; and
responsive to the receipt of said further indicator, send said set
of presence updates to said presence service client via a wireless
connection.
[0021] In yet another aspect of the below described embodiment,
there is provided a computer-implemented method comprising, at a
wireless communication device: upon detecting that a communication
client executing at said wireless communication device has become
dormant, said communication client for adapting said device to
intercommunicate via a wireless connection with any of a set of
user-specified contacts and having an associated presence service
client for receiving presence updates via said wireless connection
regarding the availability of any of said set of contacts for
intercommunication via said communication client, sending a
communication for causing said presence updates to be buffered at a
separate computing device; and upon detecting that said
communication client has ceased being dormant, receiving a set of
buffered presence updates at said presence service client from said
separate computing device via said wireless connection.
[0022] In yet another aspect of the below described embodiment,
there is provided a wireless communication device comprising at
least one processor and memory in communication with said at least
one processor, said memory storing instructions which, when
executed by said at least one processor, adapt said device to: upon
detecting that a communication client executing at said wireless
communication device has become dormant, said communication client
for adapting said device to intercommunicate via a wireless
connection with any of a set of user-specified contacts and having
an associated presence service client for receiving presence
updates via said wireless connection regarding the availability of
any of said set of contacts for intercommunication via said
communication client, send a communication for causing said
presence updates to be buffered at a separate computing device; and
upon detecting that said communication client has ceased being
dormant, receive a set of buffered presence updates at said
presence service client from said separate computing device via
said wireless connection.
[0023] In yet another aspect of the below described embodiment,
there is provided a machine-readable medium storing instructions
which, when executed by at least one processor of a wireless
communication device, adapt said device to: upon detecting that a
communication client executing at said wireless communication
device has become dormant, said communication client for adapting
said device to intercommunicate via a wireless connection with any
of a set of user-specified contacts and having an associated
presence service client for receiving presence updates via said
wireless connection regarding the availability of any of said set
of contacts for intercommunication via said communication client,
send a communication for causing said presence updates to be
buffered at a separate computing device; and upon detecting that
said communication client has ceased being dormant, receive a set
of buffered presence updates at said presence service client from
said separate computing device via said wireless connection.
[0024] Referring to FIG. 1, an instant messaging (IM) system 10 is
illustrated. The IM system 10 permits users of various types of
computing devices connected to the system 10 (through both wired
and wireless connections) to exchange textual instant messages by
way of an IM service. Although certain aspects of the IM system 10
illustrated in FIG. 1 are conventional, as will be described, the
system 10 incorporates a novel capability for efficiently
transmitting presence update information to presence service
clients.
[0025] As illustrated, the IM system 10 includes a number of
exemplary computing devices 20A, 20B, 20C and 70 operated by users
24A, 24B, 24C and 73 respectively, as well as a network 30 (which
in the illustrated embodiment is the public Internet), an IM server
40, a proxy IM server 50 and a wireless network 60.
[0026] Computing devices 20A, 20B and 20C (collectively devices 20
and generically device 20) are conventional computing devices, such
as Intel.RTM. or AMD.TM. processor-based personal computers.
Computing devices 20 have various conventional components, such as
network interface cards for providing connectivity to the Internet
30 by way of a Digital Subscriber Line (DSL) or cable modem
connection for example, input devices such as keyboards and mice
for entering data and controlling the operation of the devices 20,
display devices such as liquid crystal displays (LCDs) for
displaying graphical user interfaces (GUIs) of executing software
applications, and volatile and non-volatile memory for storing
operating system software and executable software applications
along with data (not expressly illustrated).
[0027] The memory of each device 20 stores a conventional IM client
software application ("IM client") 22. IM client 22 is a computer
program that permits a user to engage in instant messaging with
other users of a particular IM service (e.g. Yahoo!.RTM. Messenger,
AIM or Google Talk.TM.) who are also executing compatible IM
clients at remote computing devices. The responsibilities of IM
client 22 include sending and receiving instant messages at the
request of the user and automatically intercommunicating with a
central IM server 40 using a service-specific IM protocol to report
changes in the availability of the IM client user (the latter
possibly being handled by a presence service client integrated with
the IM client 22). The IM client 22 may for example be the Google
Talk.TM.0 1.0.0.100 client, Yahoo!.RTM. Messenger client with Voice
(BETA) (8.0.0.508), Windows Live Messenger 8.0 client, or GAIM
2.0.0 beta 3.1 client.
[0028] Although only three computing device 20A, 20B, 20C and three
corresponding users 24A, 24B and 24C are illustrated in FIG. 1, it
is understood that the number of computing devices and
corresponding users may actually be much greater than three,
possibly numbering in the hundreds or more.
[0029] Computing device 70 is a Research in Motion Limited (RIM)
BlackBerry.TM. two-way paging device. The device 70 is a form of
wireless communication device, which may alternatively be referred
to as a "mobile device" or "mobile station". The device 70 executes
a mobile IM client software application ("mobile IM client") 134.
Like IM client 22, mobile IM client 134 is a computer program that
adapts the device 70 to permit a user 73 to engage in instant
messaging with other users of the same IM service. The
responsibilities of mobile IM client 134 include sending and
receiving instant messages at the request of user 73. The mobile IM
client 134 has an integrated presence service client 135 which is
responsible for automatically intercommunicating with central IM
server 40, using the operative IM protocol, to report changes in
the availability of user 73. The presence service client 135 also
maintains a user-defined contact list 71 identifying all of the
users in IM system 10 with whom user 73 is frequently in contact,
as described in more detail below. As will become apparent, the
presence service client 135 incorporates program logic which
cooperates with program logic at IM proxy server 50 (described
below) to support efficient transmission of presence update
information to device 70.
[0030] IM server 40 is a conventional server executing conventional
IM server software 42 with integrated presence service capability.
The IM server software 42 effects a public IM service, such as
Yahoo!.RTM. Messenger, AIM, or Google Talk.RTM., which facilitates
instant messaging between IM clients, such as IM clients 22 and
mobile IM client 134, executing on various remote computing
devices, such as devices 20A, 20B, 20C and 70. The IM service is
referred to as a "public" service because it is generally
accessible to members of the public who choose to subscribe with
the service. This is distinguishable from an enterprise IM service,
such as IBM Lotus Sametime.TM., Novell GroupWise.RTM. and
Microsoft.RTM. Office Live Communications Server, which is
typically deployed within a secure corporate network that is not
generally accessible to the public. An alternative embodiment which
involves an enterprise IM service is described below. The
responsibilities of IM server software 42 include registering IM
users as they log into (i.e. connect to) the IM service, receiving
reports regarding the availability of users as are automatically
sent by IM clients 22 and 134, and, responsive to the received
reports, sending presence updates regarding changes in user
availability to any users who have elected to receive such
updates.
[0031] The IM server software 42 maintains a universal contact list
44. The universal contact list 44 is an amalgamation of the latest
contact list information from each user of the IM service, which in
the present example includes IM users 24A, 24B, 24C and 73. The IM
server software 42 maintains the universal contact list 44 in order
to support its presence service capability. Each time that the IM
server software 42 receives a report as to the changed availability
of a particular IM user from an IM client 22 or 134 of that user
(or associated presence service client), the software 42 consults
the list 44 in order to determine which other IM users have
expressed an interest in receiving presence updates regarding that
IM user. The IM server software 42 then proceeds to send presence
updates to those users. In the result, each user is provide with
the latest information regarding the availability of IM contacts of
interest. The contact list 44 may take the form of a database
record or electronic file for example.
[0032] Proxy IM server 50 is a conventional server executing proxy
IM server software 52. The role of the proxy IM server 50 within IM
system 10 is to act as a proxy for IM server 40 from the
perspective of wireless communication device 70, and any other
wireless communication device in communication with proxy IM server
50 via wireless network 60 (of which none are shown in FIG. 1). The
proxy IM server 50 receives IM-related communications destined for
IM server 40 from wireless communication device 70. The
communications are in the proprietary protocol of the IM service
but are carried by one or more underlying transport and network
wireless network protocols employed by wireless network 60. For
example, the protocols may include a proprietary RIM BlackBerry
Instant Messaging (BBIM) protocol encapsulating supported instant
messaging functions or a modified, wireless-friendly version of the
native Yahoo!.RTM. protocol. The proxy IM server 50 in turn relays
these communications to the actual IM server 40. To relay the
communications, proxy IM server 50 essentially maintains the
substance of the communications in the operative IM service
protocol but converts the underlying transport and network
mechanisms to whatever protocol(s) is/are appropriate for network
30. In the illustrated example, in which network 30 is the public
Internet, the latter protocols typically comprise TCP/IP. In the
opposite direction, the proxy IM server 50 serves as a proxy for
the mobile IM client 134, receiving all IM-related communications
destined for wireless communication device 70 and converting
underlying protocols in the reverse direction. The types of
IM-related communications that may be relayed by proxy IM server 50
include instant messages and presence updates.
[0033] Proxy IM server software 52 incorporates program logic that
cooperates with program logic at the presence service client 135 to
efficiently transmit presence update information to device 70.
According to this program logic, the proxy IM server software 52
buffers presence updates destined for the wireless communication
device 70 when the IM client software application 134 has become
dormant. This buffering results in a buffered set of presence
updates 54, which set is shown schematically in FIG. 1. The
presence updates 54 are ultimately sent to the wireless
communication device, once the mobile IM client software
application 134 ceases to be dormant or is about to cease being
dormant, as described in more detail below. When the mobile IM
client 134 has not been dormant for some time, there may be no set
of buffered presence updates 54 at server 50.
[0034] Proxy IM server software 52 also stores a contact list for
each mobile IM client for which it acts as a proxy. In FIG. 1, only
one contact list 71, corresponding to mobile IM client 134 of
device 70, is shown. Contact list 71 identifies all of the users of
IM system 10 with whom user 73 is frequently in contact. The
contact list 71 is generated by user 73 through interaction with
the mobile IM client software application 134 and integrated
presence service client 135 at device 70, and is automatically
communicated by mobile IM client 134 to proxy IM server 50 via
wireless network 60. Other contact lists corresponding to other
instances of mobile IM client 134 executing at other wireless
communication devices in wireless communication with proxy IM
server 50 (not illustrated) are omitted for clarity. Contact list
71 is described below in greater detail.
[0035] An executable image (i.e. machine-readable instructions) of
the proxy IM server software 52 may be loaded from a
machine-readable medium 55 into volatile or non-volatile memory of
server 50 prior to its execution by server 50. The medium 55 may
further include an executable image of mobile IM client software
application 134 (including presence service client 135), which may
be downloaded to the wireless communication device 70 via wireless
network 60 by way of an over-the-air download.
[0036] Wireless network 60 is a mobile data communication network,
such as the Mobitex.TM., DataTAC.TM. or General Packet Radio
Service (GPRS) network. Wireless network 60 may be designed to
operate with any of a variety of voice communication networks, such
as Advanced Mobile Phone Service (AMPS), Time Division Multiple
Access (TDMA), Code Division Multiple Access (CDMA), Personal
Communication Services (PCS), Global System for Mobile
communication (GSM), third generation (3G) wireless or Universal
Mobile Telecommunications Standard (UMTS) for example, to support
voice communications at the wireless communication device 70. The
wireless network 60 effects a wireless connection between proxy IM
server 50 and wireless communication device 70. The wireless
network 60 could alternatively be a IEEE 802.11 compliant ("WiFi")
wireless network, with appropriate changes to the network
topology.
[0037] Referring to FIG. 2, the wireless communication device 70 of
FIG. 1 is illustrated in greater detail. Device 70 is a two-way RF
communication device having voice and data communication
capabilities. The device 70 includes a housing, a keyboard 74, and
a display 76 which may be a color liquid crystal (LCD) display for
example. A processor, namely microprocessor 78, is coupled to the
keyboard 74 and the display 76. The microprocessor 78 controls the
operation of the display 76, as well as the overall operation of
the wireless communication device 70, in response to actuation of
keys on the keyboard 74 by the user 74 and the receipt of data
and/or voice information over wireless network 60. The keyboard may
include a mode selection key, or other hardware or software for
switching between text entry and telephony entry.
[0038] Various other parts of the wireless communication device 70
are shown schematically in FIG. 2. These include: a communications
subsystem 100; a short-range communications subsystem 102; a set of
auxiliary I/O devices 106; a serial port 108; a speaker 111; a
microphone 112; as well as memory devices including a flash memory
116 and a Random Access Memory (RAM) 118; and various other device
subsystems 120. The device 70 may have a battery 121 to power the
active elements of the device. In the present embodiment, the
wireless communication device 70 includes voice communication
capabilities. However, voice communication capabilities may not be
present in alternative embodiments.
[0039] The processor 78 executes operating system software (not
expressly illustrated) which may be stored in a persistent store,
such as the flash memory 116, or may be stored in other types of
computer-readable memory devices, such as a read only memory
(ROM--not expressly illustrated) or other storage media. The
operating system of the present embodiment is a proprietary,
multitasking operating system designed by Research In Motion
Limited (RIM) that is capable of switching between multiple,
concurrently executing software applications. At any given time,
one application is executed as a foreground process while one or
more applications may be executed as background processes. A user
73 interacting with the device 70 may cause the operating system to
change an application from executing as a background process to
executing as a foreground process (and vice-versa) in a manner that
is known in the art. As applications are executed, they may be
temporarily loaded, in whole or in part, into a volatile store,
such as RAM 118. Communication signals received by the wireless
communication device may also be stored in RAM 118.
[0040] Flash memory 116 stores various software applications 130,
132 and 134 that may be executed by processor 78. A predetermined
set of applications that control basic device operations, such as
voice and data communications 130 and 132, may be installed during
manufacture of the device 70. Other applications may be installed
either during manufacture or subsequently. These other applications
include mobile IM client software application 134 and integrated
presence service client 135, which is a focus of the present
disclosure and is described in more detail below. Flash memory 116
may further contain a number of other software modules 136. Each
module 136 may have an associated icon that is presented by the
operating system on a home screen (this is also true for mobile IM
client 134). The set of icons may be referred to as a "ribbon".
User selection of an icon from the ribbon may cause the
corresponding module 136 (or client 134) to be invoked.
[0041] RAM 118 stores contact list 71. As noted above, contact list
71 is a list generated by user 73 identifying all of the users of
IM system 10 with whom the user is frequently in contact. The list
71 may be a data record, electronic file or other data
representation. Although list 71 is illustrated separately from IM
client software application 134 in FIG. 2, it will be appreciated
that the list 71 may form part of application 134 within RAM 118,
where the application 134 may also be stored during its execution.
Contact list 71 is shown in FIG. 3 in greater detail.
[0042] Referring to FIG. 3, contact list 71 is represented as a
table. Each row of the table represents a single IM contact. For
brevity, only three IM contacts are represented in FIG. 3; the
actual number of represented IM contacts may be greater than three.
Each contact is identified in the "Contact Name" column by the IM
username of the contact. In the illustrated example, the usernames
"Joe", "Bob" and "Mary" in rows 1, 2 and 3 of the table represent
users 24A, 24B and 24C respectively of FIG. 1. The "Login
Notification" column indicates the preference of user 73 for
receiving immediate login notification in respect of the IM contact
represented by the row. A value of "enabled" in that column
indicates that user 73 wishes to be notified immediately when the
contact logs in, which in turn indicates that proxy IM server 50
should not buffer presence updates for this contact. A value of
"disabled" indicates that no such notification is desired, and that
presence updates can be buffered accordingly. The "Status" column
represents the current presence status of the contact (i.e. the
availability of the contact for instant messaging), as determined
from presence updates received in respect of the contact. In
illustrated example, the statuses indicate that user "Joe" is
available for instant messaging; user "Bob" is idle; and user
"Mary" is out to lunch. The status for "Joe" and "Bob" may be
reported by their respective IM clients 22 of these users based on
automatically detected activity or inactivity of these IM clients
22; in contrast, the status for "Mary" may be manually set by that
user. For clarity, the term "login notification" refers to a change
in presence from "offline" to any "non-offline" status. For
example, if a user logs in with a status of "invisible" (as
permitted in some networks), this may constitute a login
notification.
[0043] Referring back to FIG. 2, communication functions, including
data and voice communications, are performed by device 70 through
the communication subsystem 100, and possibly through the
short-range communications subsystem 102. The communication
subsystem 100 includes a receiver 150, a transmitter 152, and one
or more antennas 154 and 156. In addition, the communication
subsystem 100 also includes a processing module, such as a digital
signal processor (DSP) 158, and local oscillators (LOs) 160. The
specific design and implementation of the communication subsystem
100 is dependent upon the communication network in which the
wireless communication device 70 is intended to operate. For
example, the communication subsystem 100 of the wireless
communication device 70 may be designed to operate with the
Mobitex.TM., DataTAC.TM. or GPRS mobile data communication networks
and may also be designed to operate with any of a variety of voice
communication networks, such as AMPS, TDMA, CDMA, PCS, GSM, WiFi,
3G wireless and/or UMTS. Other types of data and voice networks,
both separate and integrated, may also be utilized with the
wireless communication device 70.
[0044] Network access requirements vary depending upon the type of
communication system. For example, in the Mobitex.TM. and
DataTAC.TM. networks, wireless communication devices are registered
on the network using a unique personal identification number or PIN
associated with each device. In GPRS networks, however, network
access is associated with a subscriber or user of a device. A GPRS
device therefore requires a subscriber identity module, commonly
referred to as a SIM card, in order to operate on a GPRS
network.
[0045] When required network registration or activation procedures
have been completed, the wireless communication device 70 may send
and receive communication signals over the communication network
60. Signals received from the communication network 60 by the
antenna 154 are routed to the receiver 150, which provides for
signal amplification, frequency down conversion, filtering, channel
selection, etc., and may also provide analog-to-digital conversion.
Analog-to-digital conversion of the received signal allows the DSP
158 to perform more complex communication functions, such as
demodulation and decoding. In a similar manner, signals to be
transmitted to the network 60 are processed (e.g. modulated and
encoded) by the DSP 158 and are then provided to the transmitter
152 for digital-to-analog conversion, frequency up conversion,
filtering, amplification and transmission to the communication
network 60 (or networks) via the antenna 156.
[0046] In addition to processing communication signals, the DSP 158
provides for control of the receiver 150 and the transmitter 152.
For example, gains applied to communication signals in the receiver
150 and transmitter 152 may be adaptively controlled through
automatic gain control algorithms implemented in the DSP 158.
[0047] In a data communication mode, a received signal, such as an
instant message, text message or web page download, is processed by
the communication subsystem 100 and is input to the microprocessor
78. The received signal is then further processed by the
microprocessor 78 for output to the display 76, e.g. in accordance
with an executing software application or module, or alternatively
to some other auxiliary I/O devices 106. A device user may also
compose data items, such as instant messages or email messages,
using the keyboard 74 and/or some other auxiliary I/O device 106,
such as a touchpad, a trackball, rocker switch, a thumb-wheel, or
some other type of input device. The composed data items may then
be transmitted over the communication network 60 via the
communication subsystem 100. Instant message data communication by
the device 70 is described in more detail below.
[0048] In a voice communication mode, overall operation of the
device is substantially similar to the data communication mode,
except that received signals are output to a speaker 111, and
signals for transmission are generated by a microphone 112.
Alternative voice or audio I/O subsystems, such as a voice message
recording subsystem, may also be implemented on the device 70. In
addition, the display 76 may also be utilized in voice
communication mode, for example to display the identity of a
calling party, the duration of a voice call, or other voice call
related information.
[0049] The short-range communications subsystem 102 enables
communication between the wireless communication device 70 and
other proximate systems or devices, which need not necessarily be
similar devices. For example, the short-range communications
subsystem may include an infrared device and associated circuits
and components, or a BluetoothTM communication module to provide
for communication with similarly-enabled systems and devices.
[0050] Operation of the illustrated embodiment for efficiently
communicating presence update information to presence service
clients is shown in FIGS. 4-11. FIGS. 4 and 5 are flowcharts
illustrating operation 400 of the proxy IM server software 52 and
operation 500 of the mobile IM client software application 134
respectively. FIGS. 6 and 7 illustrate state machines 600 and 700
effected by the proxy IM server software 52 and wireless
communication device 70 during the course of operation 400 and 500
respectively. With respect to FIG. 4, it should be appreciated that
the illustrated operation 400 is in respect of a single IM client
134, and that the proxy IM server software 52 may be capable of
performing operation 400 in respect of multiple supported IM
clients simultaneously. It should also be appreciated that
operation of proxy IM server software 52 for handling various other
types of IM-related messages (e.g. instant messages, which may be
received at irregular intervals) is omitted from FIG. 4 for
clarity. With respect to FIG. 5, it will be appreciated that the
illustrated operation may be implemented by a presence service
client 135.
[0051] It is initially assumed that users 24A, 24B, 24C and 73 have
used their IM clients 22 or 134 to specify IM usernames of "Joe",
"Bob", "Mary" and "Steve" (respectively) by which they shall be
known to other users of the IM service, as indicated in FIG. 1. It
is also assumed that, when operation commences, say at time 11:15
AM, only users 24C ("Mary") and 73 ("Steve") have invoked their IM
clients 22 and 134 respectively and logged into the IM service. The
IM status of both users is initially "Available". Moreover, it is
assumed that user 73 has listed users Joe, Bob and Mary in his
contact list 71 and has disabled login notification in respect of
these users, as shown in FIG. 3.
[0052] In the description of operation below, the following
definitions will be used:
[0053] (1) User activity: At wireless communication device 70, any
manipulation of keyboard 74 or other input device of auxiliary I/O
devices 106 (e.g. a touchscreen, trackball, thumb-wheel, or mouse)
when the device 70 is not in a key-locked state or password-locked
state (as defined below) is considered to constitute user activity.
When the device 70 is in a key-locked or password-locked state, any
such manipulation--including manipulation for entering a password
or for attempting to unlock the device (i.e. to remove the device
from a key-locked state or a password-locked state)--is not
considered to constitute user activity. User activity with respect
to a software application means user activity detected by an
executing software application, and may be referred to as user
interaction with the software application.
[0054] (2) Key-locked: The device 70 is considered to be in a
key-locked or "hold" state when the device 70 rejects all input
except a pre-defined unlock combination which removes the device 70
from the key-locked state. The purpose of this state is to
effectively "lock the keys" of the device 70 (i.e. make the buttons
or other input mechanisms inoperative) to avoid the accidental
generation of spurious input, as may occur if buttons are
inadvertently depressed when the device 70 in a pocket of the
user's clothing or in a purse. The device may be placed into a
key-locked state by manipulation of an electro-mechanical input
mechanism or control, such as a slide switch which resists
inadvertent depression, or automatically after the passage of a
predetermine time period with no user activity. The device may be
removed from the key-locked state by entry of the pre-defined
unlock combination, which may be a complementary manipulation of a
control (e.g. sliding the slide-switch in an opposite direction to
that which caused the device to become key-locked). In the case of
the BlackBerry device, key locking may only be available if
password locking (described below) is disabled. To key-lock the
BlackBerry device, a GUI control is selected. To unlock a
BlackBerry device, the thumb-wheel is depressed twice in
succession. Depending upon the type and manufacturer of the
wireless communication device 70, application data may or may not
be visible when a device is key-locked. For example, BlackBerry
devices do not show any application data when key-locked.
Accordingly, the key-locked state for a BlackBerry device is almost
the same as the password-locked state (defined below), except that
password entry is not required for unlocking the device. This is
not necessarily true for other types of wireless communication
devices.
[0055] (3) Password-locked: The device 70 is considered to be in a
password-locked state when a password must be entered in order to
access the device. The device may be placed into a password-locked
state at the user's initiation (e.g. through selection of a GUI
control) or automatically, upon detecting that the device has been
placed into a holster or detecting the passage of a predetermine
time period with no user activity. When in this state, no
application data (including presence information, in the case of
the IM client software application 134) is presented on a display
of the device until the correct password is entered.
[0056] (4) Presence Information Displayable: Presence information
is considered to be displayable by an IM client software
application 134 or presence service client 135 at wireless
communication device 70 when the device 70 is capable of presenting
current IM contact presence information on display 76 substantially
in real time. In the case of the BlackBerry device, this occurs
when: (a) the IM client software application 134 is executing in
the foreground; (b) the device is not key-locked; and (c) the
device is not password-locked. At other types of wireless
communication devices, the set of conditions to be met in order for
presence information to be considered to be displayable may be
different. For example, some devices may be capable of being in the
"presence information displayable" state even when key-locked, if
they continue to display current application data while key-locked.
In another example, an IM client software application GUI may be
minimized and thus may not be considered to be "in the foreground"
in a conventional sense, but may continue to display at least some
current presence information, e.g. within an icon in a "system
tray" or similar GUI construct, in which case presence information
may still be considered to be displayable.
[0057] (5) Presence Information Undisplayable: Presence information
is considered to be undisplayable by an IM client software
application at wireless communication device 70 when the device 70
does not present current IM contact presence information from the
application on display 76 substantially in real time. In the case
of a BlackBerry device, this may be for failure of the device to
meet each of conditions (a), (b) and (c) described above. In some
wireless communication device embodiments, the "presence
information undisplayable" state may also be entered either when
the device display has been placed into a power-saving mode or when
a screen saver has been activated--each of these situations
preventing current IM presence information from being seen by the
user.
[0058] Referring to FIG. 6, at the proxy IM server 50, the initial
state effected by the proxy IM server software 52 is the SEND
PRESENCE UPDATES state 602. In this state, any presence updates
received by the proxy IM server software 52 from IM server 40 in
respect of any of users Joe, Bob and Mary are sent (relayed) to the
mobile IM client software application 134 and integrated presence
service client 135 via wireless network 60. Thus, for example, if
user Mary temporarily sets her status (manually) to "do not
disturb" at 11:16 AM and then manually reverts her status to
"available" at 11:17 AM by interacting with her client 22 at
computing device 20C (FIG. 1), two presence updates reflecting
these changes in availability would be received from IM server 40
substantially in real time and relayed to mobile IM client
134/presence service client 135 via wireless network 60. This is
represented in FIG. 4 by operation S402 and S404.
[0059] At wireless communication device 70, it is assumed that,
from 11:15 AM onward, device 70 is neither key-locked nor
password-locked and mobile IM client 134 executes as a foreground
process. Referring to FIG. 7, the initial state effected by the
wireless communication device 70 is accordingly the MOBILE IM
CLIENT ACTIVE state 702. In that state, any presence updates
received from proxy IM server software 52 (such as the two
mentioned above) are processed by the presence service client 135
of mobile IM client 134, with any changes in availability being
reflected (substantially in real time) in a GUI representation of
the contact list that is displayed on the display 76 of device 70.
The receipt of such presence updates does not result in a state
change in state machine 700 and is thus represented as a transition
724 from state 702 back to state 702. The same transition 724
occurs when instant messages are received in state 702.
[0060] It is assumed that, at 11:25 AM, the mobile IM client
software application 134 becomes "dormant". This can occur in one
of two ways. First, presence information may become undisplayable
(as described above) and remain undisplayable for a predetermined
period of time TO, which may be 5 minutes for example (FIG. 7,
transition 710). Presence information could become undisplayable if
one of conditions (a), (b) or (c) described above ceases to be met.
For example, condition (a) could cease to be met if the user 73
causes mobile IM client 134 to execute as a background process by
executing a distinct application in the foreground (e.g. an email
application) for time period T0. The user may decide to use the
distinct application without terminating the IM client software
application 134 based on his knowledge that, if IM client software
application 134 receives an instant message while the distinct
application is being used, the device 70 will generate a
notification tone or otherwise notify the user of the instant
message, so that the user can elect to switch back to the IM
application if desired. The rationale for requiring presence
information to remain undisplayed for at least time period T0 is
described below. Second, there may be an absence of user
interaction with IM client software application 134 for a time
period of at least T1 (FIG. 7, transition 712). The rationale for
requiring the lack of user activity to be at least time period T1
in duration is described below. In either case, the software
application 134 transitions to a new MOBILE IM CLIENT DORMANT state
704.
[0061] Referring to FIG. 5, which shows operation of IM client
software application 134 with integrated presence service client
135, the determination in 5502 is accordingly made in the positive.
As a result, a communication is sent to the proxy IM server
software 52 to cause it to commence buffering presence updates
destined for device 70 (FIG. 5, S504). In the present embodiment,
the communication takes the form of a HOLD message 800, whose
format is illustrated in FIG. 8. As shown in FIG. 8, the HOLD
message 800 has a message type field 802 and an enable/disable
field 804, which are each one byte in length in the present
embodiment. The value 0x43 in the message type field 802 indicates
that the message pertains to the scheme for efficient transmission
of presence update information described herein. The value 0x01 in
the message type field 804 indicates "enable", i.e. hold presence
update messages.
[0062] The HOLD message 800 is received by the proxy IM server
software 52 shortly after it is sent, resulting in a transition 610
of the state machine 600 from the SEND PRESENCE UPDATES state 602
to a HOLD PRESENCE UPDATES state 604 (FIG. 6). The HOLD message 800
serves as an indicator that the mobile IM client 134 has become
dormant (FIG. 4, S402). As a result, the proxy IM server software
52 begins to buffer any presence updates destined for mobile IM
client 134 (S406).
[0063] Over the next forty minutes, it is assumed that four
presence updates regarding users Joe, Bob and Mary are received by
proxy IM server software 52 and are buffered. The buffered set of
presence updates 54 is illustrated as a table in FIG. 10.
[0064] Referring to FIG. 10, each presence update is represented as
a row within the table. For each presence update, time stamp
information, contact name information, and presence event
information is represented. The time stamp information indicates
the time at which the presence update was received. The contact
name information indicates the IM username of the contact in
respect of which the presence update was sent. The presence event
information indicates the event that has occurred which impacts
upon the availability of the contact for instant messaging. Thus,
as shown in FIGS. 10, at 11:26 AM and 11:28 AM respectively, users
Joe and Bob used their IM clients 22 to log into the IM service. At
11:48 AM, Bob's IM client reported a status of "idle", which
resulted from a failure of user Bob to interact with his IM client
22 for some predetermined time period (such as 10 minutes for
example). Then, at 12:00 PM, user Mary manually set her own status
to "out to lunch" to let others know that she will be
unavailable.
[0065] Subsequently, an event occurs at wireless communication
device 70 which results in the mobile IM client 134 ceasing to be
dormant. The event may be one of: presence information once again
becoming displayable (FIG. 7, transition 714--this assumes that
transition 710 had been the reason that the IM client software
application 134 was in state 704); user interaction with IM client
software application 134 (FIG. 7, transition 716--this assumes that
transition 712 had been the reason that the IM client software
application 134 was in state 704); or the receipt by mobile IM
client software application 134 of either of an instant message
from another IM user or a login notification regarding an IM
contact of interest (FIG. 7, transition 718), either of which may
cause a notification (e.g. tone or vibration) to be generated by
the device 70. In the case of transition 714, the event which
causes the transition may for example be user entry of a password
to cause the device to exit a password-lock state or user
manipulation of a device control to cause the device to exit a
key-lock state, followed by user interaction with IM client
134.
[0066] It will be appreciated that the transition 718 differs from
the transitions 714 and 716 because it is based on a condition
(i.e. the receipt of an instant message or login notification) that
is known to proxy IM server software 52 before it is known to IM
client 34 (since the instant message or login notification will
have come from IM proxy server software 52). For this reason, when
transition 718 occurs, it may be said that the Proxy IM server
software 52 has "taken the IM client 134 out of the dormant mode".
This is in contrast to the IM client 134 "taking itself out of
dormant mode" based on conditions known locally to IM client 134
but not known to the Proxy IM server 50 (as for transitions 714 and
716).
[0067] Regardless of which of transitions 714, 716 and 718
occurred, the software application 134 will have transitioned from
the MOBILE IM CLIENT DORMANT state 704 back to the MOBILE IM CLIENT
ACTIVE state 702. It will be appreciated that entering back into
the MOBILE IM CLIENT ACTIVE state 702 does not necessarily mean
that presence information has once again become displayable
(assuming transition 710 had been the reason for the state machine
700 being in state 704). For example, if an instant message has
been received at the IM client 134 but the device 70 remains
password-locked, state machine 700 could be in state 702 despite
the fact that presence information remains undisplayable.
[0068] The transitions 714 and 716 to MOBILE IM CLIENT ACTIVE state
702 reflect the fact that the mobile IM client 134 has ceased being
dormant. This is detected at S506 (FIG. 5). Accordingly, when
either of transitions 714 or 716 into state 702 occurs, a
communication is sent from device 70 to cause the proxy IM server
software 52 to send any buffered presence updates to presence
service client 135 (FIG. 5, S508). In the present embodiment, the
communication takes the form of an UNHOLD message 900, whose format
is illustrated in FIG. 9. As shown in FIG. 9, the UNHOLD message
900 has the same format as the HOLD message 800 of FIG. 8, with a
message type field 902 and a enable/disable field 904, each being
one byte in length. The same value 0x43 appears in the message type
field 902 as in message type field 802, whereas the value 0x00 in
the message type field 804 indicates "disable", i.e. unhold
presence update messages.
[0069] Referring to FIG. 4, the UNHOLD message 900 is received by
proxy IM server software 52 and serves as an indicator that the
mobile IM client 134 has ceased being dormant (S408). This triggers
a transition 612 of the state machine 600 from the HOLD PRESENCE
UPDATES state 604 back to the SEND PRESENCE UPDATES state 602 (FIG.
6).
[0070] Referring again to FIG. 7, it should be appreciated that
transition 718 does not cause an UNHOLD message to be sent from
device 70 to Proxy IM server 50 (unlike transitions 714 and 716).
This is to avoid unnecessary message traffic and thereby conserve
bandwidth. The UNHOLD message is unnecessary because the proxy IM
server software 52 will be aware of either of the events that cause
transition 718--i.e. receipt of an instant message or login
notification--even before IM client software application 134 is
aware of them, given that it relays such communications to the
device 70 where application 134 executes. Accordingly, when either
of an instant message or login notification are received by proxy
IM server software 52, this serves as an indication that the IM
client software application 134 will cease being dormant in the
near future, after the proxy IM server software 52 relays the
communication to application 134 so as to cause transition 718 of
FIG. 7. More specifically, referring to FIG. 6, if an instant
message destined for mobile IM client 134 is received at proxy IM
server software 52 (e.g. from an IM client 22 at another computing
device 20), then state machine 600 will transition 614 from the
HOLD PRESENCE UPDATES state 604 to the SEND PRESENCE UPDATES state
602. Similarly, if a login notification is received regarding a
contact of interest (e.g. a user named in the contact list 71 of
user 73), transition 616 from state 604 to state 606 will occur.
Thus, buffered presence updates are sent to the mobile IM client
software application 134 despite the fact that application 134 did
not send an UNHOLD message to proxy IM server software 52.
[0071] Subsequently, the proxy IM server software 52 undertakes
processing for sending the buffered presence updates 54 (FIG. 10)
to the presence service client 135. Referring to FIG. 4, a
determination is initially made as to whether it is possible to
reconcile any presence updates within the buffered set 54 (S410).
Reconciliation may be possible when two or more presence updates
can be combined into a single presence update in which obsolete
presence information is omitted. For example, referring to FIG. 10,
it may be determined that the "logged in" presence update for user
Bob received at 11:28 AM is obsolete in view of the later presence
update for user Bob received at 11:48 AM indicating that user Bob
is "idle" (since the latter status inherently indicates that Bob
has logged in). As a result, the two presence updates may be
reconciled (S412) by removing the former presence update from the
set 54. This creates a new, reconciled set of presence updates 54',
as shown in FIG. 11. Advantageously, the size of the set 54' is
smaller than that of original set 54'. This reduces the amount of
bandwidth used when the set 54' is sent to the mobile IM client
software application 134 at device 70 (S414, FIG. 4). Moreover, to
the extent that the reconciled presence updates can all be
transmitted in a single "burst", efficiency may be improved in
comparison to the transmission of presence updates individually.
Greater efficiency may result for devices that are programmed to
"awaken" from a power-saving mode and remain in that awakened
(non-power-saving) mode for some minimum period of time each time
that a presence update is received, because the device may spend
less time overall in the awakened state when presence updates
arrive in bursts. Efficiency may also be improved when multiple
presence updates are transmitted by way of a single message, in
which case the overhead associated with each presence update may be
reduced as compared with the transmission of each presence update
in a separate message. Moreover, in wireless networks which employ
message compression, the degree of compression attainable when
multiple presence updates are sent in one message may be higher
than that achievable when the presence updates are transmitted
individually, since compression may be more effective for larger
message sizes. As well, the accuracy of call statistics maintained
by wireless providers or wireless networks that deem each
transmission of one or more presence updates to constitute a "call"
may be improved. Another example of reconciliation may occur for IM
clients that are capable of indicating the current song to which an
IM contact is listening, wherein presence updates regarding
previously heard songs are omitted.
[0072] Subsequently, operation 400 and 500 of FIGS. 4 and 5, and
the transitions of state machines 600 and 700, repeat as necessary
as the mobile IM client software application 134 becomes dormant
and ceases to be dormant over time.
[0073] It will be appreciated from the above description that, for
each transition into the MOBILE IM CLIENT ACTIVE state 702, the
state machine 700 remains in that state for at least time T0 or T1.
This is done intentionally, to ensure that once mobile IM client
134 ceases to be dormant, it will spend at least time T0 or T1 in a
non-dormant state (i.e. state 702). If this were not done, and if
one of the conditions which otherwise causes transition 710 or 712
is already present when the state machine transitions into state
702, then the result would be an immediate transition back to the
MOBILE IM CLIENT DORMANT state 704. Since transitioning into the
MOBILE IM CLIENT ACTIVE state 702 causes the transmission of an
UNHOLD message 900 to the software 52 (at least in the case of
transitions 714 and 716) and transitioning back into the MOBILE IM
CLIENT DORMANT state 704 causes transmission of a HOLD message 800
from device 70 to the proxy IM server software 52, such rapid
transitions may result in an unnecessary flurry of communications
between the wireless communication device 70 and proxy IM server
50. Requiring the state machine 700 to stay in state 702 for at
least time T0 or T1 serves to mitigate this eventuality. Put
another way, if a user has received an instant message recently,
the user may be likely to receive another instant message again
soon. Thus it is desirable to prevent a transition back into state
704 too soon, even if the user has, e.g., placed the application
into the background or password-locked (or key-locked) the device.
Of course, for some embodiments, or in certain situations, it may
be determined that the additional message traffic is acceptable. In
that case, the minimum time period durations may be reduced or, in
the case of T0, avoided altogether. The use of two time periods T0
and T1 permits flexibility in configuring system behavior. In some
embodiments, this flexibility may not be required, such that only
one time period may be used for both transitions (which is what
effectively occurs if time periods T0 and T1 are both set to the
same duration).
[0074] In the above-described embodiment, the proxy IM server 50
upon which proxy IM server software 52 is executed may send IM
message traffic to wireless communication device 70 by way of a
relay server that stores and forwards communications (not only
instant messages, but other communications such as email for
example) that are destined for wireless communication device 70. In
a conventional configuration, the relay server may be situated
between the proxy IM server 50 and wireless network 60 of FIG. 1.
The relay server may thus serve as a "choke point" for
communications, including IM communications, destined for the
wireless communication device 70. By implementing the proxy IM
server software 52 in such a manner, the capability for buffering
presence updates may conveniently be provided at the server 52,
either for a single IM service or for more than one IM service,
since all IM-related communications to and from wireless
communication device 70 will be routed though the relay server.
Moreover, because no modification of the IM server software 42 is
required, the capability can be effected by an entity other than
the IM service provider. Of course, such implementation is not
required. For example, the proxy server capability that is
described above in conjunction with FIGS. 4 and 6 could be effected
at the IM server 40 in an alternative embodiment.
[0075] In another alternative, when an enterprise IM server is used
to provide IM service to users connected to a secure corporate
network within an enterprise, the proxy server capability described
above in conjunction with FIGS. 4 and 6 may be effected on a server
connected to the corporate network, rather than at a relay server.
An alternative embodiment illustrating this possibility is shown
schematically in FIG. 12.
[0076] As illustrated in FIG. 12, IM system 1000 includes a number
N of exemplary computing devices 1002A to 1002N executing client IM
software 22, as described above. Devices 1002A to 1002N are
connected to a secure local area network (LAN) 1004 that is
administered by an enterprise. Also connected to LAN 1004 is an
enterprise IM server 1006, such as IBM Lotus Sametime.TM., Novell
GroupWise.RTM. or Microsoft.RTM. Office Live Communications Server.
The enterprise IM server provides IM service to users of devices
1002A to 1002N, as well as to remote users of wireless
communication devices such as device 70 executing mobile IM client
software application 134 with integrated presence service client
135. Further connected to LAN 1004 is a proxy IM server 50'
executing proxy IM server software 52', which are similar to server
50 and software 52, described above. It is noted that, in the
embodiment of FIG. 12, the proxy IM server 50 is effected on a
BlackBerry Enterprise Server.TM., not as shown in FIG. 1. The BES
is generally responsible for monitoring the email accounts of users
of wireless communication devices such as device 70 and "pushing"
(forwarding) any received messages to the wireless communication
devices by way of firewall 1010, Internet 30, relay server 1008 and
wireless network 60. It may be desired to effect the proxy IM
server software 52' at the BES in this scenario because the BES
serves as a "choke point" for IM communications to and from the
wireless communication device 70, and possibly other wireless
communication devices. The proxy IM server software 52' may be
referred to by the commercial name BlackBerry Collaboration Service
software. Other components of server 50' are omitted for
clarity.
[0077] As will be appreciated by those skilled in the art,
modifications can be made to the above-described embodiments
without departing from the essence of the invention. For example,
wireless communication device 70 need not be a BlackBerry device
using a proprietary RIM operating system. Other forms of wireless
communication devices, such as WinCE or PalmOS operating system
based devices, or possibly even devices executing operating system
software that is not capable of multitasking, could be
employed.
[0078] In some embodiments, the format of the HOLD and UNHOLD
messages may be different from the formats shown in FIGS. 8 and 9.
For example, the hold message may be part of a "login notification
alert" sent by the IM client 134 to one or more IM contacts of
interest.
[0079] It is not absolutely necessary for the Proxy IM Server
software 52 to store the contact list 71. Since presence updates
coming from the IM Server 40 may contain all information that the
IM client software application 134 needs, the Proxy IM Server
software 52 may simply maintain the buffered presence updates 54
without maintaining the contact list 71.
[0080] In the embodiments described above, when login notification
is enabled in respect of an IM contact, no presence updates at all
are buffered for that contact (whether login notifications or
otherwise). In alternative embodiments, this setting may only
prevent the buffering of login notifications. Other types of
presence updates could feasibly still be buffered.
[0081] Fundamentally, it will be appreciated that the techniques
described in the present disclosure are applicable to presence
services and presence service clients used in any communication
system, whether associated with instant messaging, VoIP calling, or
otherwise. Presence service clients may be integrated with or
otherwise associated with communication client software
applications (such as IM clients or VoIP clients). Such
communication clients software applications could be implemented in
firmware or hardware instead of software, and thus may generically
be referred to as "communication clients". Thus the term
"communication client" may be used to refer to a software or
firmware application executing at a wireless communication device
or the wireless communication device itself. Generically, IM
contacts may be referred to as "contacts" for such systems
generally.
[0082] As well, it should be appreciated that the present
disclosure applies to peer-to-peer embodiments in which no
intermediate or central server exists. In such embodiments,
presence updates may ordinarily be sent directly from any device at
which a change in presence status has occurred to one or more other
devices (peers) that have been configured to receive (e.g. at a
presence service client) presence updates in respect of that
device. In such embodiments, a first wireless communication device
at which changes in presence status have occurred may buffer
presence updates destined for a second (peer) wireless
communication device upon receiving an indicator indicating that a
communication client executing at or comprising the second device
has become dormant. Upon receiving a further indicator indicating
that the communication client has ceased being dormant, a set of
buffered presence updates, possibly reconciled to eliminate
redundant or obsolete information, may be sent to the second
device.
[0083] Other modifications will be apparent to those skilled in the
art and, therefore, the invention is defined in the claims.
* * * * *
References