CA2499234A1 - Method and system for managing destination addresses - Google Patents
Method and system for managing destination addresses Download PDFInfo
- Publication number
- CA2499234A1 CA2499234A1 CA002499234A CA2499234A CA2499234A1 CA 2499234 A1 CA2499234 A1 CA 2499234A1 CA 002499234 A CA002499234 A CA 002499234A CA 2499234 A CA2499234 A CA 2499234A CA 2499234 A1 CA2499234 A1 CA 2499234A1
- Authority
- CA
- Canada
- Prior art keywords
- destination addresses
- addresses
- client
- user
- destination
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/48—Message addressing, e.g. address format or anonymous messages, aliases
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/58—Message adaptation for wireless communication
Description
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 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 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 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 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.
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 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 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 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 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.
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 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 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.
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 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 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.
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.
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.
Claims (6)
1. A method for downloading destination addresses from a server to a client device, each of the addresses having at least one variable attribute, the method comprising the steps of:
determining a resource limitation of the client device;
prioritising the addresses according to their attributes; and downloading a subset of said prioritised addresses to the device in order of their priority;
wherein the number of destination addresses in said downloaded subset is determined by said resource limitation.
determining a resource limitation of the client device;
prioritising the addresses according to their attributes; and downloading a subset of said prioritised addresses to the device in order of their priority;
wherein the number of destination addresses in said downloaded subset is determined by said resource limitation.
2. The method of Claim 1, wherein the client device and the server are interconnected via a wireless communications transport and said resource limitation is a speed of said transport.
3. The method of Claim 1, wherein the client device has a memory allocated for storing a received message, and said resource limitation is a maximum number of messages.
4. The method of Claim 1, wherein the client device has a memory allocated for storing said downloaded subset, and said resource limitation is a size of said allocated memory.
5. The method of Claim 1, further comprising the step of updating said downloaded subset of addresses when at least one of the variable attributes of at least one of the destination addresses changes.
6. The method of Claim 5, wherein said updating step comprises reprioritising the addresses according to their attributes; and downloading a subset of said reprioritised addresses to the device in order of their priority.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002499234A CA2499234A1 (en) | 2005-03-02 | 2005-03-02 | Method and system for managing destination addresses |
| CA2536727A CA2536727C (en) | 2005-02-16 | 2006-02-16 | Method and system for managing destination addresses |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002499234A CA2499234A1 (en) | 2005-03-02 | 2005-03-02 | Method and system for managing destination addresses |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2499234A1 true CA2499234A1 (en) | 2006-09-02 |
Family
ID=36938936
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002499234A Abandoned CA2499234A1 (en) | 2005-02-16 | 2005-03-02 | Method and system for managing destination addresses |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2499234A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106656736A (en) * | 2016-09-14 | 2017-05-10 | 广东欧珀移动通信有限公司 | Message receiving control method and terminal equipment |
-
2005
- 2005-03-02 CA CA002499234A patent/CA2499234A1/en not_active Abandoned
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106656736A (en) * | 2016-09-14 | 2017-05-10 | 广东欧珀移动通信有限公司 | Message receiving control method and terminal equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8880730B2 (en) | Method and system for managing destination addresses | |
| US8874671B2 (en) | Electronic message metering and traffic management in a networked environment | |
| EP1574085B1 (en) | Instant messaging and presence services | |
| US6973299B2 (en) | Unified contact list | |
| US9648115B2 (en) | Alerts for monitoring user status | |
| US9369850B2 (en) | Automated caller identifier from contact lists of a user's contacts | |
| US7747762B2 (en) | System for transmitting data utilizing multiple communication applications simultaneously in response to user request without specifying recipient's communication information | |
| US7536191B2 (en) | Push-to-talk communications in computing environments | |
| US20090221307A1 (en) | Group communications | |
| US20080031225A1 (en) | Aggregating endpoint capabilities for a user | |
| US8700075B2 (en) | System and method for managing messages in conversational-type messaging applications | |
| KR101544518B1 (en) | Method, device and system for sharing microblog message | |
| US9654427B2 (en) | Presenting instant messages | |
| AU2004279203A1 (en) | System and method for a user interface directed to discovering and publishing presence information on a network | |
| CA2634220A1 (en) | Contact list display system and method | |
| US20100198923A1 (en) | Methods for using the addressing, protocols and the infrastructure of email to support near real-time communication | |
| KR20090046124A (en) | Method for displaying a other party's terminal information by using the presence and mobile terminal thereof | |
| KR20110103611A (en) | Social network service system and social network service method | |
| CA2536727C (en) | Method and system for managing destination addresses | |
| CA2499234A1 (en) | Method and system for managing destination addresses | |
| US8630666B2 (en) | Triggering email/PIM events based on SMS headers and content | |
| EP2627046B1 (en) | Electronic message metering and traffic management in a networked environment | |
| KR101140213B1 (en) | Mobile Comunication Terminals Having Function of Managing User Name, Managing System Using the Same and Method thereof | |
| EP2391076A2 (en) | Method and device for real-time e-mail communication | |
| WO2010055503A2 (en) | Method and device for providing communication services to a telephone user |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |