Note: Descriptions are shown in the official language in which they were submitted.
CA 02499234 2005-03-02
1
TITLE OF THE INVENTION
METHOD AND SYSTEM FOR MANAGING DESTINATION ADDRESSES
FIELD OF THE INVENTION
The present invention relates to a method and system for managing
destination addresses. In particular, the present invention relates to a
method
for and system for managing and downloading destination addresses to a
mobile device having limited resources in terms of memory and/or bandwidth
based on one or more variable attributes of the destination address.
BACKGROUND OF THE INVENTION
As known in the art, Instant Messaging (IM) services such as AIM and ICQ,
amongst others, allow a user to maintain a contact list (or buddy list)
comprising the destination addresses of other users they may wish to interact
with. A user is alerted when another user matching one of the entries in his
contact list goes online, and a real-time exchange of messages can take
place with any of these users provided they are currently on line (present)
and
not otherwise busy. In one embodiment of an IM service, initiating sending a
message to a user opens up a small window, or dialog box, through which
both users can interact in real-time by typing in text.
IM services, as are the majority of open distributed applications, are often
based on a client-server architecture, where a large number of clients,
typically in the form of software modules located on devices being used by
individual users (such as a personal computer, PDA or the like) communicate
with one or more centralised servers. The server typically responds only to
requests for services which are initiated by the client. In this regard, the
client
will initiate establishment of a (logical) communications channel with the
server, and once established bidirectional communications can take place
CA 02499234 2005-03-02
2
between client and server. Once a communication channel has been
established between the server and a client, IM services can take advantage
of the channel for the transfer of relevant IM service information. As stated
above, one type of information provided and managed by IM services are
contact lists.
For IM services which are implemented using personal computers and high
speed wired or wireless networks, arbitrarily long contact lists may be used.
Additionally, the attributes (or status) of individual entries in the contact
list
typically change over time as users come online or go offline, become
engaged with other users, etc. In order to support the display of arbitrarily
long
contact lists and maintain currency of the displayed information, sizeable
display capabilities, large available memory and frequent signalling are
required. In cellular networks, where the constraints on device capabilities
and
network capacity are more severe, storing and maintaining status information
for arbitrarily large lists of destination addresses is much more challenging.
IM services typically additionally allow a user to group contacts into smaller
subsets of lists (co-workers, buddies, etc.) for easier manipulation. Existing
wireless mobile instant messaging systems allow the user to create a specific
contact list for usage on a mobile device. For example, U.S. Patent number
6,714,793 for a "method and system for instant messaging across cellular
networks and a public data network", the entire contents of which is
incorporated herein by reference, describes a communications system for
sending a message from a wireless device over a wireless communication
network. The disclosed method allows for use of destination addresses that
were previously stored on the device. The method also allows the user to add
new destination addresses via the device handset, but does not allow
additional addresses to be collected from the communications network.
Similarly, the Open Mobile Alliance (OMA) Wireless Village Standard allows
for the mobile device to request the network to supply a contact list of
CA 02499234 2005-03-02
3
destinations addresses using the ListManageRequest primitive. However,
there is no description in the standard on how to limit the size of a contact
list,
for example by requesting less than the complete contact list. Furthermore,
there is no provision in this standard for allowing the server to
interactively
modify the content of a contact list located at a client during a session. The
Wireless Village Standard allows for the user to modify the contact list
content
using the ListManageRequest, but this again does not allow for dynamic
management on the part of the server to modify the content of the contact
list.
Mobile devices usually contain an address book (AB), where the user may
enter phone numbers of contacts. This address book may also include
additional fields such as ernail addresses. However, these address books do
not include fields for destination addresses for instant messaging contacts.
As
a result, there is no mechanism for associating instant messaging destination
addresses with other identities in the mobile device (e.g. with the
information
in the device address book).
SUMMARY OF THE INVENTION
In order to overcome the above and other drawbacks, a first part of the
present invention relates to the management of a set of destination addresses
and the status of the users identified by these destination addresses for
instant messaging clients, in particular on mobile devices.
As stated above, systems providing IM services provide for a list of
destination addresses (contact lists or buddy lists). These lists furthermore
show the presence status (or attributes) of the user identified by the
destination addresses.
A method of truncating the list size is required, as well as a mechanism to
update the list in the mobile device. In cellular networks, the problem of
updating the list is further compounded by the fact that users may access
their
CA 02499234 2005-03-02
4
IM service for long periods of time, during which the presence status of the
destination addresses may change repeatedly. The proposed mechanism
provides for more efficient use of mobile network resources by updating only
when the underlying IM service is actively in use in the client device and
when
the changes are sufficient to impact usability. The proposed mechanism also
takes into consideration that there are variations in capabilities of client
devices and transport mechanisms.
A second part of the present invention relates to the management of users
identified by multiple destinations addresses.
In systems providing IM services, users are frequently identified by specific
destination addresses within the system. These users may also be known
through other identities in the mobile devices, such as their name, nick name,
telephone number or e-mail address. There is currently no mechanism
available by which the identity of a user in a system providing IM services
can
be associated with other identities that the same user has elsewhere in a
mobile device for retrieval/storage of the IM destination address from/to
another identity associated with the user, or another identity from/to the IM
destination address.
Additionally, although the description of the methods described hereinbelow is
within the context of a mobile IM service, they apply in general to services
where:
The user is presented with a set of destination addresses. Due to the
constraints of the terminal device, this set of addresses may require
significant compression if it is to be displayed or stored on a mobile device,
as
compared to when displayed on a PC device;
the destination addresses possess dynamic attributes that are relevant
as discrimination criteria for compressing the set, and are susceptible to
CA 02499234 2005-03-02
change while the user is accessing and using the service; or
~ the user accesses and makes use of the service for periods of
sufficient duration for significant changes to occur in the status of the
dynamic
5 attributes of the destination addresses.
When one or more of these conditions are present, the methods described in
hereinbelow by way of an illustrative embodiment thereof enable a
compressed set of destination addresses to be initially provided to the mobile
device based on relevant dynamic attributes of the destination addresses, and
to be subsequently updated based on the changes in the status the dynamic
attributes. As a first example, these methods could be applied to a Push-to-
talk (PTT) service, in which the compression of the set of destination
addresses provided to the mobile device would be based on the availability of
the destination addresses for engaging in a PTT call, and not already
engaged in another call. As a second example, these methods could be
applied to a gaming service, in which the compression of the set of
destination
addresses provided to the mobile device would be based on the availability of
the destination addresses for engaging in the game, and not already playing
another game.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is schematic diagram of an instant messaging system in accordance
with an illustrative embodiment of the present invention;
Figure 2 is a front view of a hand held mobile client device in accordance
with
an illustrative embodiment of the present invention; and
Figure 3 is a flowchart of a method for managing a set of destination
addresses stored on a mobile device.
CA 02499234 2005-03-02
6
DETAILED DESCRIPTION OF THE ILLUSTRATIVE EMBODIMENTS
Referring now to Figure 1, a system for managing contact addresses,
generally referred to using the reference numeral 10, in accordance with an
illustrative embodiment of the present invention will be described. The system
comprises a plurality of clients as in 12 which are arranged for
communication with one or more servers as in 14 in a client-server
relationship. In this regard, communication pathways between individual
clients, for example between client 12~ and client 122, are established via
the
10 servers) 14. Communication links, or transport, as in 16 between clients
and
server can be supported by a variety of communications means, for example
wireless or wired connections, and typically consist of a concatenation of
heterogeneous communication systems (all not shown). As a result, the
clients as in 12 may be either mobile, for example in the form of a software
module executing in a mobile handset or the like, or fixed, for example in the
form of a software module executing in a desk top system.
Referring to Figure 2 in addition to Figure 1, each client as in 12 further
comprises a user interface comprised of a display 18 and an input device 20,
such as a key board, touch screen, mouse, etc. Additional items, typically in
the form of a software application, such as a client device address book 22
are also provided in particular embodiments.
Referring now to Figure 3 in addition to Figures 1 and 2, the mechanism for
managing the set of destination addresses stored on a mobile device will now
be described with reference to the flowchart.
When presented with a contact list comprised of a set of destination
addresses to be downloaded to a client 12, the server 14 must determine the
maximum size suitable for the client 12 and the transport 16 being used ('*1'
in the flowchart). The client 12 capabilities may be previously known to the
server 14 (for example, configured in memory), or may be supplied by the
CA 02499234 2005-03-02
7
client 12 at the time that the request to download the contact list of
destination
addresses is made. Alternatively, the server 14 may determine, based on the
type of transport (for example, SMS), that the list must be fixed at a certain
predetermined amount (for example, thirty (30) destination addresses).
If the number of destination addresses in a contact list is greater than
allowed
for a particular client 12 or transport 16, the system must select which
subset
will be sent to the client 12 ('*2' in the flowchart). For example, referring
now
to Figure 2, to provide a visual indication to the user, each destination
address
as in 24 is typically tagged with a descriptive icon as in 26 indicating the
current presence status (attribute) of the user identified by that particular
destination address 24. Typically, presence status indicates one of "online",
"mobile", "busy°, "away", or "offline". In an illustrative embodiment,
the
destination addresses 24 in the contact list would be prioritized according to
their presence status and those addresses whose presence status indicates
that they are "online" would be downloaded first, followed by destination
addresses whose presence status indicates that they are "mobile", "busy",
"away", etc., until the maximum number of destination addresses is reached.
Referring back to Figure 1 and 3 in addition to Figure 2, as the presence
status of the destination addresses changes over time (e.g. from "offline" to
"online"), a mechanism is provided for refreshing the set of destination
addresses 24 in the client 12. A number of different triggers may be used
('*3'
in the flowchart). For example, one trigger may be that the user manually
refreshes the set by selecting via the input device 20 a menu entry which is
displayed to the user in the display 18, triggering an action in the client
12.
Alternatively, the server 14 could detect that it is an appropriate time to
send
an updated set of destination addresses 24 to the client 12. For example,
using the current Wireless Village protocol as a basis, with the addition of a
new extension to indicate a dynamic update of the destination addresses, a
manual refresh may be generated using the "ListManage" primitive.
Alternatively, another method would allow the server 14 to include the set of
CA 02499234 2005-03-02
8
destination addresses 24 (or update to the set) during a presence update.
This could be accomplished with the addition of an appropriate extension to
the Wireless Village primitives GetPresence or PresenceNotification.
Once the server 14 has detected a trigger to dynamically update the set of
destination addresses 24, the server 14 must again select which subset will
be sent to the client 12 ('*4' in the flowchart). As the client 12 is
currently in a
session, there may be one or more destination addresses having a presence
status indicating "in conversation". In this example, an illustrative
embodiment
of selecting the subset of destination addresses 24 would be to prioritize
them
in the order "in conversation", "online", "mobile", "busy", "away", or
"offline"
and download those destination addresses 24 having presence status
indicating "in conversation" first, followed by "online", "mobile", "busy",
"away",
and "offline" up until the maximum number of destination addresses has been
downloaded.
In an alternative embodiment, the entire contact list could be divided into a
series of smaller contact lists, each of the smaller contact lists comprising
a
subset of all those destination addresses which would otherwise form part of
the contact list. Provision would also be made to allow the user to view the
smaller contact lists one list at a time. For example, the default contact
list
may include all destinations addresses where the presence status indicates
"online", with subsequent contact lists containing the remaining destination
addresses arranged, for example, alphabetically. Illustratively, the client 12
would retrieve the identities of the set of smaller contact lists with the
Wireless
Village primitive GetListRequest. The default list could then be retrieved
using
the ListManageRequest primitive. The user would then be presented with the
option to view the other lists (e.g. using a "next page" command or the like).
When selected, the client would use the ListManageRequest primitive with
reference to the subsequent contact list identifier (Contact-List-ID) to
download the next in the series of smaller contact lists.
CA 02499234 2005-03-02
9
On login to an IM service, the server 14 provides to the client 12 one or more
attributes associated the destination addresses 24. These attributes can
include, for example, UserID (of the destination address in the IM service),
contact name, email address, telephone number, etc.. The client 12 inspects
the device address book 22 to determine if some of these attributes match
with equivalent attributes of entries stored in the device address book 22.
Upon positive match, the client 12 would associate the destination address 24
with the entry stored within the device address book 22. This association can
be automatic, or alternatively could require confirmation from the user.
The IM service may also offer the user the ability to manually associate a
destination address 24 with an entry stored within the device address book 22
(for example, the client 12 could prompt the user the option of selecting an
entry in the device address book 22 and linking the destination address 24 to
the entry). Once this association is made, the user could be given the option
to communicate with a particular destination address via a means other than
via instant messaging. For example, the user could select to transmit an e-
mail message or to phone the other user identified by that destination
address.
Alternatively, the association could be stored by the client 12 within the
device
address book 22 following which the device address book 22 could be used
by the to user to send instant messages to the user identified by the entry in
the device address book 22.
Although the present invention has been described hereinabove by way of an
illustrative embodiment thereof, this embodiment can be modified at will
without departing from the spirit and nature of the subject invention.
