Imposed policies for handling instant messages

Chat sessions are managed between at least one sending computer and a receiving computer. A first chat session is initiated by a receiving computer in response to a first request from a first sending computer. A second chat session is initiated by the receiving computer in response to a second request from a second sending computer. The first and second chat sessions are prioritized in accordance with priority parameters to identify a higher priority chat session and a lower priority chat session. The lower priority chat session is restricted until the higher priority chat session is downgraded to a priority level that is below the lower priority chat session.

BACKGROUND

The present disclosure relates to the field of computers, and specifically to messages between computers. Still more particularly, the present disclosure relates to instant messaging.

BRIEF SUMMARY

Chat sessions are managed between at least one sending computer and a receiving computer. A first chat session is initiated by a receiving computer in response to a first request from a first sending computer. A second chat session is initiated by the receiving computer in response to a second request from a second sending computer. The first and second chat sessions are prioritized in accordance with priority parameters to identify a higher priority chat session and a lower priority chat session. The lower priority chat session is restricted until the higher priority chat session is downgraded to a priority level that is below the lower priority chat session.

DETAILED DESCRIPTION

Note that the terms “instant messaging” and “chat”, as well as “instant messaging session” and “chat session”, as used herein are understood to be interchangeable terms used to describe real-time communication between two or more users using typed text, which is communicated between computing devices that are coupled over a network. Similarly, any other terms and/or phrases that incorporate the terms “instant messaging” or “chat” are considered to be interchangeable.

With reference now to the figures, and in particular toFIG. 1, there is depicted a block diagram of an exemplary computer102, which may be utilized by the present invention. Note that some or all of the exemplary architecture, including both depicted hardware and software, shown for and within computer102may be utilized by software deploying server150and/or other computer(s)152.

Computer102includes a processor unit104that is coupled to a system bus106. Processor unit104may utilize one or more processors, each of which has one or more processor cores. A video adapter108, which drives/supports a display110, is also coupled to system bus106. In one embodiment, a switch107couples the video adapter108to the system bus106. Alternatively, the switch107may couple the video adapter108to the display110. In either embodiment, the switch107is a switch, preferably mechanical, that allows the display110to be coupled to the system bus106, and thus to be functional only upon execution of instructions (e.g., instant messaging management program—IMMP148described below) that support the processes described herein.

System bus106is coupled via a bus bridge112to an input/output (I/O) bus114. An I/O interface116is coupled to I/O bus114. I/O interface116affords communication with various I/O devices, including a keyboard118, a mouse120, a media tray122(which may include storage devices such as CD-ROM drives, multi-media interfaces, etc.), a printer124, and (if a VHDL chip137is not utilized in a manner described below), external USB port(s)126. While the format of the ports connected to I/O interface116may be any known to those skilled in the art of computer architecture, in a preferred embodiment some or all of these ports are universal serial bus (USB) ports.

As depicted, computer102is able to communicate with a software deploying server150and a sender's SMTP server152via network128using a network interface130. Network128may be an external network such as the Internet, or an internal network such as an Ethernet or a virtual private network (VPN).

Application programs144in computer102's system memory (as well as software deploying server150's system memory) also include an instant message management program (IMMP)148. IMMP148includes code for implementing the processes described below, including those described inFIGS. 2-5. In one embodiment, computer102is able to download IMMP148from software deploying server150, including in an on-demand basis. Note further that, in one embodiment of the present invention, software deploying server150performs all of the functions associated with the present invention (including execution of IMMP148), thus freeing computer102from having to use its own internal computing resources to execute IMMP148.

Also stored in system memory136is a VHDL (VHSIC hardware description language) program139. VHDL is an exemplary design-entry language for field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and other similar electronic devices. In one embodiment, execution of instructions from IMMP148causes VHDL program139to configure VHDL chip137, which may be an FPGA, ASIC, etc.

In another embodiment of the present invention, execution of instructions from IMMP148results in a utilization of VHDL program139to program a VHDL emulation chip151. VHDL emulation chip151may incorporate a similar architecture as described above for VHDL chip137. Once IMMP148and VHDL program139program VHDL emulation chip151, VHDL emulation chip151performs, as hardware, some or all functions described by one or more executions of some or all of the instructions found in IMMP148. That is, the VHDL emulation chip151is a hardware emulation of some or all of the software instructions found in IMMP148. In one embodiment, VHDL emulation chip151is a programmable read only memory (PROM) that, once burned in accordance with instructions from IMMP148and VHDL program139, is permanently transformed into a new circuitry that performs the functions needed to perform the process described below inFIGS. 2-5.

With reference now toFIG. 2, an exemplary graphical user interface (GUI)200displaying multiple chat windows202a-das utilized by the present disclosure is presented. One or more of the chat windows202a-dmay be displayed as “pop-ups” in response to a chat partner sending a chat message. A most recently used chat window may be highlighted and/or displayed alone while other chat windows are hidden (not shown). Alternatively, a chat window control bar204, having tabs206a-dfor respective chat windows202a-d, may be used to allow a user to manually display one or more of the chat windows202a-d. In either scenario, however, without the present invention a user is unable to throttle back how many chat sessions he is participating in. That is, while a user may not want to eliminate a chat partner from a list of approved chat partners, that user may still want to manage and control which chat partners are given priority when engaged with the user. Without the presently disclosed method and apparatus, such “throttling” is impractical, if not impossible.

One embodiment of the present invention is illustrated in an exemplary manner inFIG. 3, which depicts a chat session request receiving computer302responding to chat session requests from one or more chat session request sending computers304a-b. Chat session request receiving computer302is analogous to computer102described above and shown inFIG. 1, and chat session request sending computers304a-bare analogous to other computer(s)152shown inFIG. 1. Similarly, a user of chat session request receiving computer302views the GUI200, indicating that the user is being overwhelmed by too many chat sessions if the present invention is not implemented.

Assume that first chat session request sending computer304ainitially sends a chat session request306to chat session request receiving computer302. Utilizing a session supervisor301, which may be part of IMMP148shown inFIG. 1, chat session request receiving computer302first checks a local session queue308to see how many chat session participants are “in front of” a user of the first chat session request sending computer304a. Based on that user's position in line, a ticket number310is returned to the first chat session request sending computer304a. This ticket number310describes what place the user of first chat session request sending computer304aholds in session queue308. This allows a session monitor312(which in one embodiment is a component of IMMP148shown inFIG. 1) to monitor when the user of first chat session request sending computer304ais authorized to engage in a chat session with a user of chat session request receiving computer302. Subsequently, a second user, who is using second chat session request sending computer304b, sends a chat session request316to chat session request receiving computer302. This chat session request316results in another ticket number318being sent to session monitor320. Thus, ticket number318is a lower priority ticket number and ticket number310is a higher priority ticket number, thus giving the user of the first chat session request sending computer304aa higher place in line in session queue308than a user of the second chat session request sending computer304b. In this scenario, the holder of the lower priority ticket number must wait until the holder of the higher priority ticket number has completed or otherwise terminated (e.g., allowed a timer to expire) his chat session with the chat session request receiving computer302.

Unless the user of second chat session request sending computer304bhas been granted an overriding higher priority, by session supervisor301, which allows him to effectively override and terminate a current chat session between chat session request receiving computer302and some other computer (e.g., first chat session request sending computer304a), the user of second chat session request sending computer304bthen takes the last place in line in session queue308. If session supervisor301does allow the user of second chat session request sending computer304bto evict (override and terminate) the current chat session being held with the first chat session request sending computer304a, then a message may be sent from the chat session request receiving computer302to the first chat session request sending computer304astating “Your session is suspended for the time being due to a higher priority communication.” This message may be displayed on the GUI used by first chat session request sending computer304a. As depicted inFIG. 3, one embodiment of the present disclosure provides the chat session request receiving computer302with the ability to supervise the prioritization, initiation, and terminations of all chat sessions from multiple chat session request sending computers304a-b. In another embodiment, this control can be performed by a supervisory computer (not shown), which is in communication with the chat session request sending computers304a-bas well as the chat session request receiving computer302.

Assume now that chat sessions with a user of chat session request receiving computer302are only going to occur one chat session at a time, and that no user has priority over another user. In this embodiment, whoever is at the top of the session queue308is the user that will be allowed to have a chat session with the user of the chat session request receiving computer302. In such an embodiment, each user who is waiting for a chat session has to wait until he is at the top of session queue308. In order to know what place they hold in the session queue308, waiting users view a GUI400(shown inFIG. 4) on their respective computers. GUI400lets the user know what his ticket number is (402a), how many other users are waiting to have a chat session (402b), and what the estimated wait time is until the user will be at the top of the queue (402c). Elements402a-care automatically updated by chat session request receiving computer302using software found in IMMP148.

With reference now toFIG. 5, a high-level flow-chart of exemplary steps taken in a more complex embodiment of the present invention is presented. After initiator block502, which may be prompted by a user (e.g., an end user of chat session request receiving computer302shown inFIG. 3; a system administrator; etc.), or a set of rules and/or policies associated with and set for a receiving computer, determining that the user needs to throttle and control who is able to have chat sessions with her (and under what parameters/criteria/guidelines), a receiving computer sets priority parameters for chat session participants (block504). These priority parameters may be set by the receiver of the request for a chat session, a remote manager, business logic, emergency conditions, etc. For example, the priority parameter may be simply based on “who asked first” when requesting a chat session with the receiving computer. In another embodiment, specific users (which may be identified by specific IDs in a table—not shown) are assigned priorities, such that one specific person has priority over another specific person when engaging in a chat session with the receiving computer. In another embodiment, the priority parameter is based on a relationship with a chat session requester and the receiving user. Thus, a boss, babysitter, spouse, customer, etc. may be given higher priority over friends, distant relatives, etc. In such a scenario, a receiver's boss may be able to “kick off” another chat session participant if that boss has a higher priority than the other chat session participant. Likewise, a chat requester who deems his chat to be an emergency (or who has previously been given ultimate priority) will be able to usurp control of the receiving computer's chat session execution. Note that, in one embodiment, setting priority parameters as shown in block504is performed once for all future chat sessions. That is, the priority parameters are set by the receiving user and/or rules/policies such that all future chat sessions are controlled according to these priority parameters. Thus, any future higher-priority chat user that evicts a lower-priority chat user is also controlled by these same priority parameters, and thus can be evicted by an even higher-priority user.

Referring now to block506, a first chat session between the receiving computer (e.g., chat session request receiving computer302shown inFIG. 3) and a first sending computer (e.g., first chat session request sending computer304a) is initiated. In one embodiment, when this first chat session (or another higher priority chat session) is initiated, a GUI on the sending computer that is having a chat session is temporarily blocked from displaying any other application windows other than a chat window. Thus, the user of the sending computer is forced to focus all attention on the chat session, resulting in the chat session with the receiving computer likely being shorter. Similarly, if the user of the receiving computer does not respond to a chat message from the sending computer within a predetermined period of time, the receiving computer will automatically send the sending computer a pre-set message, such as “Your message is important; please stand by”, an advertisement, streaming music, etc., all of which are designed to ask the user of the initial sending computer for more time while the user of the receiving computer composes a responsive instant message.

If another user wants to initiate a chat session with the receiving computer (query block508), then the existing chat session participant and the new requesting chat session participant and their actual/potential sessions are prioritized (block510) in accordance with the priority parameters set in block504. This prioritization results in a lower-priority chat session being restricted (block512), such that this lower-priority chat session has fewer privileges that a higher-priority chat session. In one embodiment, these lower privileges mean that the lower-priority chat session is suspended until it is elevated to a higher-priority chat session (e.g., the previous higher-priority chat session is ended).

In one embodiment, prioritizing chat sessions (block510) results in active and waiting chat sessions/users being placed in a queue (e.g., session queue308shown inFIG. 3), which can be used to generate ticket numbers in a manner described above. This queue, along with the waiting chat sessions/users, can be displayed on a GUI at the receiving computer, thus allowing the user of that computer to know how many sessions/users are in line. If too many chat sessions/users are in that user's queue, then the user or software logic can make appropriate adjustments (e.g., re-routing waiting sessions/users to another service representative, sending updated wait messages to the waiting users, etc.). In one embodiment, restricting the lower priority chat session until the higher priority chat session is downgraded to a priority level that is below the lower priority chat session is performed by the chat session request receiving computer (e.g.,302) temporarily preventing itself from displaying, on its own GUI, anything other than the chat window for the higher priority chat session. In another embodiment, this restricting is performed by the chat session request receiving computer still displaying other windows, including other chat windows, but only allowing the chat window for the current higher priority chat session to be active. In this embodiment, other windows, including browser windows, e-mail windows, etc. are still active, but only the higher priority chat session window among the chat session windows is also active.

Referring now to query block514, a current chat session may change. That is, the current chat session may end (i.e., ending the current chat session is an ultimate downgrading of the current higher priority chat session to a priority level that is below a lower priority chat session); a user with a higher priority may be requesting a chat session (thus resulting in the current user being “kicked out”); etc. If so, then chat session features are adjusted (block516). This adjustment may be kicking a current chat user off, sending a message to the current chat user that his session is over (due to the current chat user affirmatively choosing to end the chat session in response to a “Are you done?” message; a time-out period elapsing; a higher-priority user requesting a new chat session; etc.), modifying how many chat sessions can be held simultaneously by the receiving computer, etc. If the current chat session is ended, then in one embodiment the user who just finished the chat session may be prevented from initiating another chat session with the receiving computer until all other existing sessions/users in the session queue have had their turn at a chat session with the receiving computer.

As soon as there are no more sessions/users in the session queue (query block518), indicating that all chat sessions have ended, the process ends (terminator block520).