|Publication number||US20090070433 A1|
|Application number||US 12/275,224|
|Publication date||Mar 12, 2009|
|Filing date||Nov 21, 2008|
|Priority date||Sep 30, 2003|
|Also published as||US7499974, US8935338, US20050071435, US20100106792, US20150026284|
|Publication number||12275224, 275224, US 2009/0070433 A1, US 2009/070433 A1, US 20090070433 A1, US 20090070433A1, US 2009070433 A1, US 2009070433A1, US-A1-20090070433, US-A1-2009070433, US2009/0070433A1, US2009/070433A1, US20090070433 A1, US20090070433A1, US2009070433 A1, US2009070433A1|
|Inventors||Christopher K. Karstens|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Referenced by (12), Classifications (14)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
The present invention relates to computer software, and deals more particularly with techniques for managing user information in instant messaging systems.
2. Description of the Related Art
Instant messaging systems are a popular communications mechanism for many people, and provide for instant, real-time communication between users who are connected to the system through an on-line or electronic networking environment such as the Internet, World Wide Web (hereinafter, “Web”), or corporate internal intranets. Examples of instant messaging systems include Yahoo!® Messenger, AOL Instant MessengerSM, and Lotus Instant Messaging and Web Conferencing. (“Yahoo!” is a registered trademark of Yahoo! Inc. and “AOL Instant Messenger” is a service mark of America Online, Inc.)
Instant messaging systems provide real-time awareness of who is logged on. Typically, an instant messaging (hereinafter, “IM”) system user has an address book or “buddy list” containing names or nicknames for those people with whom he communicates. The entries in this address book are used for selecting a message recipient. In addition, the IM system (“IMS”) typically indicates, using a visual cue (such as different icons or different fonts), which of the people in the address book are logged on to the system and which are not. When the message sender and the target recipient are both currently logged on to an IMS (which may be the same IMS, or a different IMS), a message can be delivered and presented to the recipient nearly instantly (depending on network delay).
Instant messaging systems are often used for communicating among friends, and are also becoming integral business tools that enable team members or other business associates to communicate more efficiently and effectively (e.g., as they collaborate on a project).
An IMS user may also have user groups defined in his address book, where a user group comprises individual users (each of whom may also have a separate entry in the address book) and, optionally, other groups. Over time, as a user adds more and more people (or groups) to his address book, a situation arises where a number of these people/groups will not actually engage in IM sessions with the user in the near term (where “near term” may be defined in various ways, including this week, this month, this year, etc.). For example, a user “Joe” may have 300 entries in his IM address book, whereas he only engages in IM sessions on a weekly basis with 5 of these people.
In current IM systems, an IM server manages functions, such as “presence” detection, of the address book equivalently for all users. “Presence”, for an IMS, is the function whereby the IM display for a user such as Joe is dynamically updated to indicate which users from Joe's address book are currently online (and are therefore available for participating in an IM session). As can be imagined, as Joe's address book grows larger over time, the amount of system resources expended in performing management functions such as presence increases. The presence function, for example, is typically notified when a user's IM client comes online, and this presence function then notifies other IM users of the new client presence. When a user's IM client becomes inactive, enters a “do not disturb” state, or goes offline, it sends a message to the presence server, which in turn communicates that information to other IM users. In a situation such as the example described above, where Joe only interacts with 5 users but has 300 entries in his address book, a very unproductive use of resources results due to current IM servers managing functions (such as presence) of all these users. The overall efficiency of the IM server is seriously degraded when there are a number of users in this same situation.
One solution to this problem would be for Joe to simply delete users or groups from his address book, as he finds he does not interact with them frequently. However, if he subsequently wishes to engage in an IM session with a deleted user or group, he will need to manually re-enter their information into his address book. Re-entering information is time-consuming, and therefore most users do not find this approach acceptable.
Accordingly, what is needed are improvements to the management of user information in IM systems.
An object of the present invention is to provide techniques for improving the management of user information in IM systems.
Another object of the present invention is to provide techniques whereby user entries in an IM address book can be treated as “expired”, without actually deleting those entries.
A further object of the present invention is to provide techniques for managing expired IM address book entries differently from non-expired entries to thereby improve efficiency of an IMS.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention may be provided as methods, systems, and/or computer program products. In one aspect, the present invention comprises techniques for managing user information in an IMS by: determining, for an IM client, whether users remembered by the IM client should be treated as expired; and omitting those users which are to be treated as expired when performing selected IM management functions.
The omitting preferably includes omitting the expired users when performing presence determination. The determination preferably further comprises using expiration criteria selected by a user of the IM client. This determination may comprise one or more of: comparing a first date when an instant message last arrived from a particular user to a second date selected by a user of the IM client; determining whether an instant message last arrived from a particular user more than a specified length of time before the current time; comparing a first date when an instant message was last sent by a user of the IM client to a particular user to a second date selected by the IM client user; and determining whether an instant message was last sent by a user of the IM client user to a particular user more than a specified length of time before the current time.
The determination may be triggered in several ways, including by scheduling an action to analyze expiration information for each presently-unexpired user; performing the evaluation of each presently-unexpired user at configured intervals; and/or by scheduling an expiration action for each of one or more users, where each user will then be treated as expired upon execution of the scheduled expiration action for that user.
Optionally, the determination may further comprise selecting, by a user of the IM client, one or more users that will then be automatically treated as currently expired.
The determination and the omitting may also be performed for user groups remembered by the IM client.
The determination may use default expiration criteria, and a user of the IM client may be allowed to selectively override the default expiration criteria.
This aspect may further comprise receiving an inbound message from a particular user who is being treated as expired, and then treating the particular user as no longer expired, responsive to the receiving. In addition or instead, this aspect may further comprise sending an outbound message from the IM client to a particular user who is being treated as expired, and then treating the particular user as no longer expired, responsive to the sending.
A distinct visual indicator is preferably used for those users who are being treated as expired when presenting those users' names on a display to a user of the IM client. The users remembered by the IM client are preferably those users having entries in an address book used by the IM client.
In another aspect, the present invention provides techniques for managing user information in an IMS, comprising: determining, for an IM client, whether users remembered by the IM client should be treated as expired; and providing a different visual representation for the remembered users who are to be treated as expired, as contrasted to the remembered users who are not to be treated as expired, when displaying an IM client display to a user of the IM client.
The different visual representation may, for example, comprise using an italicized font when displaying names or nicknames of the remembered users who are to be treated as expired, as contrasted to a non-italicized font used when displaying names or nicknames of the remembered users who are not to be treated as expired. In addition or instead, the different visual representation may comprise omitting the names or nicknames of the remembered users who are to be treated as expired when displaying the IM client display to the IM client user.
The present invention may also be used advantageously in methods of doing business, for example by providing improved management of users in an IMS. This may comprise: evaluating, for an IM client, which of the users remembered by the IM client should be treated as expired; providing, for the IM client, an indication for those users which are to be treated as expired; and charging a fee for carrying out the evaluation and providing the indication. The fee for this improved management may be collected under various revenue models, such as pay-per-use billing, monthly or other periodic billing, and so forth.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.
The present invention provides techniques for improving the management of user information in IM systems. One or more users or user groups may “expire” from a particular IM client user's perspective. When a user or user group has expired, the IMS no longer includes that user or group in the management functions it performs for that particular IM client user. As a result, unproductive overhead is reduced and the overall efficiency of the IMS may be significantly improved.
The sample GUI display 100 in
According to preferred embodiments, users and groups expire automatically when expiration criteria are met. This automatic expiration is also referred to herein as the “auto-expire” or “auto-expiration” of users or groups. In addition, a user may explicitly force selected users or user groups into an expired status. This is also referred to herein as “on-demand expiration”. The manner in which these operations are performed in preferred embodiments will now be described in more detail.
Preferably, a set of default auto-expiration information is defined at the level of an individual IM client user, and the IM client user is allowed to override these default values for selected users and/or groups in the IM client user's address book. Or, if default values are not provided, the IM client user is allowed to configure his IM client with a set of default values. (A data structure that may be used to record information used for expiration of users and groups is described below, with reference to
According to preferred embodiments, the expiration of users and groups from one IM user's perspective preferably has no effect on the status of those users or groups in the IM client of another user. For example, if a user “Bob” meets the auto-expiration criteria for Joe's IM client, this has no impact on how Bob is represented in any other IM user's client.
An auto-expiration value may be specified as a relative value or an absolute value. An inbound auto-expiration value may be specified as a relative value by selecting a particular period of time, as shown at 211. Suppose, for example, that Joe selects an inbound auto-expiration value of 3 months. This selection indicates that a user should be automatically expired from Joe's address book if no inbound IM message is received from that user within the most recent 3 months. This provides a “sliding expiration date” approach, whereby auto-expiration decisions are made by looking backwards from the current date to see if there has been any IM activity with the user during the applicable time period. For example, if Joe's auto-expiration value for inbound messages is 3 months, and a message last arrived from Jane on Jul. 30, 2003, then Jane will be automatically expired unless she sends a new message before Oct. 30, 2003. Suppose Jane does send a new message on Oct. 1, 2003. In this case, her auto-expiration date will be automatically changed to Jan. 1, 2004.
As an alternative to the sliding-date approach, an implementation may use the entries at element 211 of
When an inbound auto-expiration value specified in terms of a time period is applied to a user group, the user group is automatically expired when an inbound IM message has not been received from any of the group members in the specified time period.
As an alternative to using a relative period of time as has been described with reference to element 211, an inbound auto-expiration value may be specified as an absolute value, for example by selecting a particular calendar date. This is illustrated in
Use of absolute expiration dates may, in some cases, result in new users being instantly expired. For example, if Joe sets an auto-expiration date of Feb. 1, 2003, then any new entries he creates in his address book after that time will be instantly expired (since the expiration date has passed).
Preferably, when a user or group is expired, in addition to omitting that user or group when performing management functions (as discussed above), a visual representation of that user or group on the IM client display is distinct from the visual representations of unexpired users and groups. The IM client display thereby provides a quick and easy-to-use presentation of expiration information (in addition to the presence information provided by prior art IM systems).
Preferred embodiments are described herein with reference to using italicization to visually indicate those users and groups that have expired (although this is by way of illustration, and not of limitation). In preferred embodiments, the expired users and groups are presented on the IM client display in the same relative locations where they appear when using a prior art IM client display, but the user name or group name of each expired user and group is presented in an italicized font. This is illustrated in
Note that, in this example display 300, the typical icons that indicate presence have also been removed for these expired users and group, since the expired status indicates that the IMS should no longer check their presence. Alternatively, a specific icon that is designed to indicate the expired status may be displayed. Particular colors may also be used to indicate those users and group which are expired. Referring again to
A number of optional functions may also be supported by an implementation of the present invention, and the IM user may be allowed to configure these functions. Representative functions are shown generally at elements 230 and 240, and will now be described.
Optionally, expired users and groups may be automatically moved to a selected folder, as shown by the configurable option at element 231. In this case, the IM user can display the folder contents for an at-a-glance view of which users and groups are expired. Those expired users and groups are then preferably removed from the IMS display of unexpired users, which allows the IM client user to see a less-cluttered view.
In the general case, expired users and groups are not actually deleted from the IM user's address book. This approach is useful in case the user or group subsequently becomes active again, in which case the IM user does not need to re-enter information into his address book. An option may be provided, however, that allows a particular IM user to specify that expired users and groups should be deleted. This option is shown at element 232 of
Users may also be allowed to selectively enable the expiration function. Elements 233 and 234 are provided in the example configuration display 200 for this purpose (for the inbound case), whereby the IM user can separately enable the expiration function as applied to users and to groups.
If an inbound IM message arrives from an expired user or group, an implementation of the present invention may optionally be adapted for automatically “reviving” that user or group. Or, the IM user may be allowed to selectively enable this revival function. In the latter case, the user may be allowed to enable the revival function separately for individual users and for groups, as shown at elements 235 and 236 (for the inbound case). When a user is revived, the auto-expiration value for that user is preferably automatically set to the default value (e.g., a default time period as specified at element 211 or a fixed date as specified at element 212). Similarly, when a user group is revived, the auto-expiration value for each user is preferably automatically set to the default value.
An option may also be provided whereby the IM user can set the “last inbound date” to the current time, as shown at element 240 (for the inbound case). For example, if IM user Joe last received an inbound message from Sally on Apr. 1, 2003 but selects this option as of Oct. 1, 2003, then Sally's information will record that a message from Sally was received on Oct. 1, 2003.
As another example of using the box shown at element 240, suppose Joe has configured an auto-expiration interval of 4 months, and that a message was last received from Sam on Jan. 1, 2003. The auto-expiration date for Sam is therefore May 1, 2003. Now suppose that on Feb. 1, 2003, Joe decides to change Sam's auto-expiration interval to 2 months instead of 4. Since the last message received from Sam was Jan. 1st, Sam's auto-expiration date will then be Mar. 1, 2003. However, Joe may elect to check the “Set last inbound date to current time” box 240. In that case, Sam's information will be changed to reflect arrival of a message on February 1st, and his new auto-expiration date will then be Apr. 1, 2003.
If a user changes auto-expiration values, this may cause instant expirations in some cases. For example, with reference to the scenario just described, if Joe changes Sam's auto-expiration interval to 2 months on Mar. 15, 2003 (but does not use box 240 to change last-arrival information), then Sam will be instantly expired.
Note that an implementation of the present invention may use the time, as well as the date, when determining expiration. Therefore, omission of time-of-day considerations in the examples discussed herein is not by way of limitation.
Outbound auto-expiration information may be specified in a similar manner to specification of inbound information. Thus, element 250 of
Note that options have not been provided in
Turning now to
The row 470 for user Ann, for example, indicates that Joe last sent an IM message to Ann on Jan. 1, 2003 (column 420), and also last received a message from Ann on that same date (column 440). An auto-expiration time for outbound messages (column 430) is set to 6 months for this user, and this same auto-expiration time is used for inbound messages (column 450). Assuming that the current date is more than 6 months later than Jan. 1, 2003, the expiration status (column 460) for Ann is set to “expired”. The row 472 for user Carol, on the other hand, indicates that Carol's expiration status is “active” (column 460). This row further indicates that Joe last sent an IM message to Carol on Aug. 1, 2003 (column 420), and last received a message from Carol on Aug. 2, 2003 (column 440). Carol's auto-expiration time for outbound messages (column 430) is set to 3 weeks, as is her auto-expiration time for inbound messages (column 450). Assuming that the current date is less than 3 weeks after the dates of Aug. 1, 2003 and Aug. 2, 2003, Carol is an active user.
When different values are specified for the outbound auto-expiration and the inbound auto-expiration, an implementation of the present invention preferably uses the first-occurring one of these two dates when determining whether a particular user or user group has expired. Alternatively, a single value that applies to both inbound and outbound auto-expiration may be used without deviating from the scope of the present invention. In this latter case, columns 430 and 450 are replaced by a single auto-expiration column, and that single value is used to determine whether a user or group has expired. Or, a user may configure his implementation so that either an inbound date or an outbound date, but not both, is evaluated. (See the discussion of elements 233 and 234 of
If the IM user changes the inbound and/or outbound auto-expiration values once entries such as those depicted in table 400 are already created, for example by entering a new time period at element 211 of
The auto-expiration values may be checked, for each unexpired user and group, by scheduling an evaluation action or event with a task scheduler, such that the evaluation will occur on a certain date. When the scheduled evaluation event is performed, any entries meeting their auto-expiration criteria will then be marked as expired. As another alternative, instead of scheduling an auto-expiration evaluation event, the checking of auto-expiration values may be performed periodically, e.g., at some configurable interval (such as monthly) or upon occurrence of some event (where the user may be allowed to specify the triggering event or events). (Another alternative that uses a task scheduler for scheduling auto-expiration events for IM users directly, rather than scheduling evaluation events, is described below prior to the discussion of
User groups may have rows in table 400, as shown at 476 and 478. The group row preferably comprises the dates messages were last received from, and sent to, any member of this group, along with the group-level auto-expiration values. A group expiration status is also stored. As an alternative to including a row in table 400 for each group, the table may be limited to rows for individual users, in which case a separate data structure may be used to record the group names and to remember which users are members of each group. In this case, if the separate group-level data structure is not adapted for recording the last-sent and last-received information for the group, that information is preferably re-computed each time the auto-expiration checking is carried out by evaluating each unexpired user who is a group member.
When rows for groups are present in table 400, a pointer, linked list, or similar reference (not shown in
When an outbound message is sent to a target user, an embodiment of the present invention preferably locates that user's row in table 400 and revises the date-last-sent value in column 420. If this target user (i.e., recipient) is a member of one or more groups, then the value of column 420 in the row for each group is updated as well. When Joe sends a message to a group, the date-last-sent value in column 420 of that group's row is updated, and the row for each group member is preferably updated as well. Similarly, when Joe receives an inbound message from any user, the date-last-received value in column 440 is revised, and the row for any group in which this user is a member is also preferably revised. (
In another approach, a task scheduler is used for scheduling auto-expiration events. That is, rather than scheduling an evaluation event to analyze stored dates as described above, these scheduled auto-expiration events result in automatically expiring an IM user when the event is triggered or “fires”. These auto-expiration events may be scheduled in several different ways, including upon addition of a new IM user (e.g., in a buddy list or address book), manual action by the end user, and occurrence of IM actions such as receiving an inbound instant message or sending an outbound instant message.
Suppose, for example, that a new IM user “Paul” is defined for Joe's IM system, in which default auto-expiration is currently set to 2 months. If the user definition occurs on June 1st, then an auto-expiration event will be automatically scheduled with the task scheduler for August 1st. If the event fires on that date, then Paul is set to expired status. Next, suppose that on July 1st, Joe decides to change Paul's auto-expiration interval to 10 days instead of 2 months. An embodiment of the present invention using this approach then programmatically searches through the task scheduler's scheduled events until locating the auto-expiration event associated with Paul. Upon finding this scheduled event, the date is changed (or this existing event is deleted and a new event is created), such that the auto-expiration event for Paul will now fire on July 11th.
Using this approach for the general case, before a scheduled event date is changed, the new date is preferably compared to the stored date (if found), and the scheduled event date is then set to the new date only if the new date is earlier than the stored date (or there is no stored date). Scheduled event dates set to past dates will immediately trigger the event.
As another example, updating the scheduled auto-expiration event in this manner may be triggered by receipt of a new instant message from Paul. If Joe has configured his IM client to automatically expire other IM users if no messages are received within 3 months, for example, then each time an inbound instant message arrives from a particular user, the task scheduler's events are preferably scanned to locate any already-scheduled auto-expiration event for that user. Upon locating an event, it is updated or replaced, as just discussed, such that the event will now fire in 3 months time.
As yet another example, Joe might use a GUI display such as display 200 in
A task scheduler's auto-expiration events may be scheduled and/or altered responsive to other types of actions or other triggering events, and thus these examples are presented by way of illustration but not of limitation.
Turning now to
If this user/group is not currently expired, then the projected date when the user or group will expire is preferably shown in
On the other hand, if the user/group has already expired, then the date of expiration may be shown at element 522 and/or 532.
The IM user is preferably allowed to change the auto-expiration value for either or both of the inbound and outbound cases. While display 500 shows a simple dialog box at elements 521 and 531 as being used for this purpose, this choice of entry mechanism is for drafting convenience. An actual implementation preferably provides options such as those shown at 211 and 212 of
The auto-expiration of users and groups has been discussed heretofore with reference to receiving and sending IM messages. In an optional aspect, additional types of events may be used when determining the date to be used in the auto-expiration computations. For example, Joe may specify that he is to be notified if user Ann becomes active (e.g., if Ann's presence is detected by the presence function), and this notification may be used when determining auto-expiration status. One or more additional columns may be added to table 400 to track the dates of such events. As an alternative, the value in either column 420 or column 440 may be updated upon occurrence of such events. For example, the date-last-received value in column 440 of row 470 in Joe's table 400 might be updated upon either (i) receiving an inbound message from Ann or (ii) receiving notification that Ann is currently active for instant messaging. Accordingly, this updated value may then be used in subsequent auto-expiration comparisons to determine Ann's expiration status.
An on-demand expiration function may also be provided, as noted earlier, whereby an IM user can selectively change the expiration status of users and/or groups. With reference to display 300 of
When the user selects “Expire Now” from the pop-up menu after having selected a user or group name, the auto-expiration logic is triggered, and the relative and/or absolute dates existing in the table 400 are ignored for the selected user or group. The user may have selected more than one user and/or group, for example by using some type of multi-select capability, in which case the dates for all of the selected entries from table 400 are ignored. Instead of using the dates from table 400, the expiration time for the selected entry or entries is set to the current date, and the expiration status (column 460) for each such entry is automatically set to expired. When the on-demand function “Expire Now” is applied to a group, the entry for each group member in table 400 is revised accordingly. The newly-expired users and user groups are then preferably depicted using a visual indicator such as italicized font, a special icon, and/or special colors for the foreground and background text, as discussed above with reference to
In an optional aspect, rather than automatically expiring the entry or entries when the user selects “Expire Now”, the automatic expiration may be conditioned upon whether the IM user has configured his IM client such that the expiration function is enabled for users and/or groups. Refer to the discussion of elements 233 and 234 of
In one aspect, selecting “Configure Expiration Settings” from the pop-up menu enables the IM user to configure expiration settings that apply globally to all users and groups. In this case, a display such as that shown in
Selecting “Reset Expiration Settings” from the pop-up menu preferably enables the IM user to set new values for the default expiration settings (e.g., using a display such as that shown in
The pop-up menu choices “Chat”, “Remove”, and “Edit Nickname” preferably invoke IMS functions as in the prior art. That is, the “Chat” selection preferably triggers an IMS function for message creation, the “Remove” selection preferably enables the IM user to delete selected users and user groups, and the “Edit Nickname” function allows the IM user to change the nickname for one or more of the users or groups defined in his IM address book. The “Alert Me When” function may proceed as in the prior art, whereby the IM user identifies criteria that comprise one or more events for which this user wishes to be notified. According to an optional aspect of the present invention, this “Alert Me When” function may also be used to define an event that, when triggered, provides an additional date as input to the auto-expiration computations, as has been discussed above.
Referring again to
Referring now to
Block 620 tests whether a sliding date approach is being used. As has been discussed with reference to
Control reaches Block 640 when a sliding date approach is being used. Block 640 adds the auto-expiration interval value to the last message date, as has been described above with reference to
Blocks 840-850 pertain to rows having an expired status in column 460. In preferred embodiments, Block 840 tests whether the IM user who received this inbound message has enabled the automatic revival function described above with reference to elements 235 and 236 of
As has been demonstrated, the present invention provides advantages over prior art IM systems, which may have significant processing overhead. The techniques disclosed herein are more efficient that prior art techniques, and are easy for the IM user to understand, configure, and use.
It should be noted that while preferred embodiments of the present invention have been described with reference to IM systems, the disclosed techniques may be leveraged by other status-aware applications or systems and/or other systems that provide functions such as presence. Furthermore, while preferred embodiments are described with reference to an IM system's “address book”, this term is used as a shorthand reference to any data structure or structures with which an IM client is able to remember the users and/or user groups with which it has engaged, or will engage, in instant messaging.
The disclosed techniques may also be used advantageously in methods of doing business, for example by providing improved management of users in an IMS. As an example of how this may be provided, a service may be offered that (1) evaluates, for an IM client user, which of the users remembered by the IM client should be treated as expired; and (2) provides, for the IM client, an indication for those users which are to be treated as expired. Typically, a fee will be charged for carrying out the evaluation and providing the indication. The fee for this improved management may be collected under various revenue models, such as pay-per-use billing, monthly or other periodic billing, and so forth.
As will be appreciated by one of skill in the art, embodiments of the present invention may be provided as methods, systems, or computer program products. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product which is embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-readable program code or instructions embodied therein.
The present invention has been described with reference to flowchart illustrations and/or block diagrams usable in methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions, which may be stored on one or more computer-readable media, may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create computer-readable program code means for implementing the functions specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart and/or block diagram block or blocks.
While the preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims shall be construed to include preferred embodiments and all such variations and modifications as fall within the spirit and scope of the invention.
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7590696 *||Jul 21, 2004||Sep 15, 2009||Aol Llc||Enhanced buddy list using mobile device identifiers|
|US8577972||Jan 19, 2010||Nov 5, 2013||Facebook, Inc.||Methods and systems for capturing and managing instant messages|
|US8775529 *||May 8, 2009||Jul 8, 2014||Raytheon Company||Bridging communications between communication services using different protocols|
|US8935338||Jan 4, 2010||Jan 13, 2015||International Business Machines Corporation||Instant message user management|
|US9047364||Jan 16, 2013||Jun 2, 2015||Facebook, Inc.||Intelligent client capability-based results related to a character stream|
|US9053173||Jan 28, 2013||Jun 9, 2015||Facebook, Inc.||Intelligent results related to a portion of a search query|
|US9053174||Jan 30, 2013||Jun 9, 2015||Facebook, Inc.||Intelligent vendor results related to a character stream|
|US9053175||Jan 30, 2013||Jun 9, 2015||Facebook, Inc.||Intelligent results using a spelling correction agent|
|US9070118||Sep 14, 2012||Jun 30, 2015||Facebook, Inc.||Methods for capturing electronic messages based on capture rules relating to user actions regarding received electronic messages|
|US9075867||Jan 31, 2013||Jul 7, 2015||Facebook, Inc.||Intelligent results using an assistant|
|US9075868||Feb 13, 2013||Jul 7, 2015||Facebook, Inc.||Intelligent results based on database queries|
|US20100287226 *||Nov 11, 2010||Raytheon Company||Bridging Communications Between Communication Services Using Different Protocols|
|International Classification||H04L29/06, H04L12/58, H04L29/08, G06F15/16|
|Cooperative Classification||H04L51/04, H04L12/581, H04L12/585, H04L69/329, H04L67/24, H04L29/06|
|European Classification||H04L51/04, H04L29/06, H04L12/58B|