Instant messaging activity notification

RELATED APPLICATION

0001This application claims priority under 35 U.S.C. § 119 or 365 to Great Britain, Application No. 0703276.6, filed Feb. 20, 2007. The entire teachings of the above application are incorporated herein by reference.

TECHNICAL FIELD

0002This invention relates to activity notification in an instant messaging system.

BACKGROUND

0003Instant messaging (“IM”) is a popular form of computer-based communication in which text-based messages are exchanged between users in real-time. To use an instant messaging system, user terminals of the users must be connected to a communications network, such as the internet, and an instant messaging client application must be executed on the user terminal. The client application allows a user to initiate an instant messaging conversation with a remote user, by establishing a connection over the communications network. The user can then type a message and send it to the remote user (by pressing “enter” or actuating a “send” button), and the message is displayed in the user interface of the client of the remote user in near real-time (depending on network delays). The remote user may then subsequently type a reply and send it to the other user. The exchange of messages can continue in this way, in a similar form to face-to-face verbal conversation.

0004IM therefore has significant advantages over other text-based forms of electronic communication, such as email, in that it is much more interactive and therefore provides a much richer user experience. However, due to the fact that typing a message can take a significant period of time, a situation often arises where one of the users does not know that the other is typing a message, and therefore types his own message as well. This results in the two users frequently sending messages either at the same time or in close succession, thereby resulting in the IM equivalent of talking over each other. This can interrupt the flow of the conversation and make it stilted.

0005In order to improve the flow of the conversation, indicators are known that provide an indication to the participants of the IM conversation that one of them is typing. For example, when a user starts typing a messaging in an input field of an IM client a message is created and transmitted over the communications network to the remote user. In response to receiving the message, the client of the remote user displays a notification of the form “user X is typing”. This provides a visual indication to the remote user that the user is typing, thereby prompting the remote user to wait until the message has been sent before typing his own message. This aids the flow of the conversation by preventing the users typing over each other.

0006A first method for controlling the display of an IM activity indicator is disclosed in U.S. Pat. No. 6,301,609. In this method, whenever activity from the keyboard is sensed in the IM client, a message is transmitted to the remote user. The reception of this message prompts the user interface of the remote user's client to display an activity notification. The client of the transmitting user starts a timer after sending the notification message, such that if further activity is not sensed within a predetermined time interval then a second message is sent indicating that activity has stopped. Reception of this second message prompts the user interface of the remote user's client to remove the activity notification.

0007A second method for controlling the display of an IM indicator is disclosed in U.S. Pat. No. 6,519,639. This discloses a method in which keyboard activity is sensed at the IM client, and an activity message is transmitted to the remote user. The reception of this message prompts the user interface of the remote user's client to display an activity notification. The client then waits for a predetermined time interval, and if there was any activity at the IM client within this time interval, then a further activity message is sent to the remote user. After the remote user's client has received an activity message, this also starts a timer, such that if a further activity message is not received when the timer expires, the activity notification displayed to the remote user is deleted.

0008An extension to the second method above is disclosed in U.S. Pat. No. 6,631,412, whereby the activity notification displayed to the remote user is deleted when the actual message comprising the information typed by the user is received at the remote user's terminal.

SUMMARY

0009Mere indication of whether input from the keyboard has occurred within a particular time interval does not accurately represent the actual user behaviour in an IM conversion. For example, a user often starts typing and then changes his mind and deletes a message. In the above-mentioned methods, this results in the remote user's client displaying an activity indicator, even though there is no message being prepared. The result of this is significant interruption to the flow of conversation, due to the delays involved when a remote user is waiting for a message that will never arrive. This is because the remote user's client is dependent on the timer to update the activity indicator. This results in user frustration, and makes the conversation stilted. A further problem with IM activity indication messages is that they are triggered regardless of whether the input was deliberate on the part of the user or not. Again, this will create expectation of a message on the part of the receiver, and hence frustration at the lack of a subsequent message.

0010There is therefore a need for a technique to address the aforementioned problems with IM activity notifications.

0011According to one aspect of the present invention there is provided a method of communicating user activity in a messaging system, comprising: monitoring an input region displayed to a first user of the messaging system in a client executed at a user terminal of the first user; responsive to receiving a user activated input at said input region, analysing said input and using said analysis to match said input to a type of user activity from a predetermined set of user activities; and transmitting a message comprising data representing said type of user activity from the user terminal of said first user to a user terminal of at least one other user of the messaging system over a communications network.

0012In one embodiment, the method further comprises the steps of: receiving said message at the user terminal of said at least one other user; extracting the data representing said type of user activity from the message; comparing the type of user activity from the message with a last known activity state of the first user and determining an action to take responsive to said comparison; and updating an indicator of user activity displayed in a user interface of a client executed at the user terminal of said at least one other user in accordance with said action.

0013Preferably, said action comprises one of: removing the indicator from the user interface; replacing the indicator with a different indicator; or maintaining the indicator in the user interface. Preferably, said predetermined set of user activities includes at least one of: a typing activity; a deletion activity; an accidental input activity; an angry user activity; a message completed activity; and a message cancelled activity.

0014In another embodiment, the method further comprises the steps of: comparing the time period since receiving an input at said input region to a predetermined time interval; and in the case that the time period since receiving an input at said input region exceeds said predetermined time interval, transmitting a message comprising data representing user inactivity from the user terminal of said first user to a user terminal of at least one other user of the messaging system over a communication network.

0015Preferably, said step of analysing said input comprises detecting the actuation of a specific control on an input device of the user terminal of the first user. Preferably, said step of analysing said input comprises detecting the repeated actuation of a control on an input device of the user terminal of the first user. Preferably, said step of analysing said input comprises detecting the actuation of a plurality of controls that are grouped physically on an input device of the user terminal of the first user. Preferably, said step of analysing said input comprises detecting the simultaneous actuation of a plurality controls on an input device of the user terminal of the first user. Preferably, said step of analysing said input comprises detecting the number of characters present in the input region.

0016Preferably, the communication network is a peer-to-peer network.

0017According to another aspect of the present invention, there is provided a messaging system, comprising: a communication network; a user terminal of a first user of the messaging system connected to the communication network; and a user terminal of at least one other user of the messaging system connected to the communication network, wherein said user terminal of the first user executes a client, said client comprising: means for monitoring an input region displayed to the first user of the messaging system; means for analysing a user activated input, responsive to receiving said input at said input region, and using said analysis to match said input to a type of user activity from a predetermined set of user activities; and means for transmitting a message comprising data representing said type of user activity from the user terminal of said first user to the user terminal of the at least one other user of the messaging system over the communication network.

0018In one embodiment, the user terminal of the at least one other user executes a client, said client comprising: means for receiving said message at the user terminal of said at least one other user; means for extracting the data representing said type of user activity from the message; means for comparing the type of user activity from the message with a last known activity state of the first user and determining an action to take responsive to said comparison; and means for updating an indicator of user activity displayed in a user interface of the client executed at the user terminal of said at least one other user in accordance with said action.

0019Preferably, said action comprises one of: removing the indicator from the user interface; replacing the indicator with a different indicator; or maintaining the indicator in the user interface. Preferably, said predetermined set of user activities includes at least one of: a typing activity; a deletion activity; an accidental input activity; an angry user activity; a message completed activity; and a message cancelled activity.

0020In another embodiment, said client executed on the user terminal of the first user further comprises: means for comparing the time period since receiving an input at said input region to a predetermined time interval; and means for transmitting a message comprising data representing user inactivity from the user terminal of said first user to a user terminal of at least one other user of the messaging system over a communication network, in the case that the time period since receiving an input at said input region exceeds said predetermined time interval.

0021Preferably, said means for analysing said input comprises means for detecting the actuation of a specific control on an input device of the user terminal of the first user. Preferably, said means for analysing said input comprises means for detecting the repeated actuation of a control on an input device of the user terminal of the first user. Preferably, said means for analysing said input comprises means for detecting the actuation of a plurality of controls that are grouped physically on an input device of the user terminal of the first user. Preferably, said means for analysing said input comprises means for detecting the simultaneous actuation of a plurality controls on an input device of the user terminal of the first user. Preferably, said means for analysing said input comprises means for detecting the number of characters present in the input region.

0022Preferably, the communication network is a peer-to-peer network.

0023According to another aspect of the present invention, there is provided a user terminal connected to a communication network and executing a client for use in a messaging system, said client comprising: means for monitoring an input region displayed to a user of the user terminal; means for analysing a user activated input, responsive to receiving said input at said input region, and using said analysis to match said input to a type of user activity from a predetermined set of user activities; and means for transmitting a message comprising data representing said type of user activity from the user terminal to a user terminal of at least one other user of the messaging system over the communication network.

0024According to another aspect of the present invention, there is provided a computer program product comprising program code means which when executed by a computer implement the steps according to the above method.

BRIEF DESCRIPTION OF THE DRAWINGS

0025For a better understanding of the present invention and to show how the same may be put into effect, reference will now be made, by way of example, to the following drawings in which:

0026<figref idref="DRAWINGS">FIG. 1</figref> shows an instant messaging system;

0027<figref idref="DRAWINGS">FIG. 2</figref> shows a flowchart of a method for controlling activity notifications in an IM system;

0028<figref idref="DRAWINGS">FIG. 3</figref> shows a user terminal executing client software;

0029<figref idref="DRAWINGS">FIG. 4</figref> shows a main user interface of a client;

0030<figref idref="DRAWINGS">FIGS. 5A and 5B</figref> show user interfaces during an IM conversation for User A and User B;

0031<figref idref="DRAWINGS">FIG. 6</figref> shows a flowchart for a method of providing activity notification messages that accurately reflect user behaviour;

0032<figref idref="DRAWINGS">FIG. 7</figref> shows the structure of an activity notification message;

0033<figref idref="DRAWINGS">FIG. 8</figref> shows a flowchart of the process performed at a client following receipt of an activity notification message;

0034<figref idref="DRAWINGS">FIGS. 9A and 9B</figref> shows user interfaces displayed for normal typing activity;

0035<figref idref="DRAWINGS">FIGS. 10A and 10B</figref> shows user interfaces displayed for deletion activity;

0036<figref idref="DRAWINGS">FIGS. 11A and 11B</figref> shows user interfaces displayed for angry user activity;

0037<figref idref="DRAWINGS">FIGS. 12A and 12B</figref> shows user interfaces displayed for accidental input activity; and

0038<figref idref="DRAWINGS">FIG. 13</figref> shows a user interface for a multichat.

DETAILED DESCRIPTION

0039Reference is first made to <figref idref="DRAWINGS">FIG. 1</figref>, which illustrates an instant messaging system <b>100</b>. A first user of the IM system (denoted “User A” <b>102</b>) operates a user terminal <b>104</b>, which is shown connected to a network <b>106</b>, such as the Internet. The user terminal <b>104</b> may be, for example, a personal computer (“PC”), personal digital assistant (“PDA”), a mobile phone, a gaming device or other embedded device able to connect to the network <b>106</b>. The user terminal <b>104</b> has an interface means to receive information from and output information to a user of the device. In a preferred embodiment of the invention the interface means of the user terminal <b>104</b> comprises a display means such as a screen and a keyboard and mouse. The user terminal <b>104</b> is connected to the network <b>106</b> via a network interface <b>108</b> such as a modem, and the connection between the user terminal <b>104</b> and the network interface <b>108</b> may be via a cable (wired) connection or a wireless connection. The user terminal <b>104</b> is running a client <b>110</b>. The client <b>110</b> is a software program executed on a local processor in the user terminal <b>104</b>, which provides the IM connections between the users of the IM system. The client is described in more detail with reference to <figref idref="DRAWINGS">FIGS. 3</figref>, <b>4</b> and <b>5</b> hereinafter.

0040Also connected to network <b>106</b> is at least one other user of the IM system <b>100</b>. For example, <figref idref="DRAWINGS">FIG. 1</figref> illustrates User B <b>112</b> operating a user terminal <b>114</b> and connected to the network <b>106</b> via a network interface <b>116</b>. User terminal <b>114</b> executes client software <b>118</b> similar to client <b>110</b> executed on the user terminal <b>104</b> of User A <b>102</b>. <figref idref="DRAWINGS">FIG. 1</figref> also illustrates further users, Users C and D (<b>120</b> and <b>122</b>, respectively), who are connected to the network <b>106</b> with user terminals (<b>124</b>, <b>126</b>) executing clients (<b>128</b>, <b>130</b>) via network interfaces (<b>132</b>, <b>134</b>).

0041Note that, in practice, there may be a very large number of users connected to the IM system, but these are not illustrated in <figref idref="DRAWINGS">FIG. 1</figref> for clarity.

0042In preferred embodiments, the clients of the IM system <b>100</b> communicate using a peer-to-peer (“P2P”) network topology built on proprietary protocols. An example of this type of communication system is the Skype™ system. To access the peer-to-peer network, the user must execute client software provided by the operator of the P2P system on their user terminal, and register with the P2P system. When the user registers with the P2P system the client software is provided with a digital certificate from a central server. Once the client software has been provided with the certificate, communication can subsequently be set up and routed between users of the P2P system without the further use of a central server. In particular, the users can establish their own communication routes through the P2P system based on exchange of one or more digital certificates (or user identity certificates, “UIC”) to acquire access to the P2P system. The exchange of the digital certificates between users provides proof of the user's identity and that they are suitably authorised and authenticated in the P2P system. Therefore, the presentation of digital certificates provides trust in the identity of the user. It is therefore a characteristic of peer-to-peer communication that the communication is not routed using the central server but directly from end-user to end-user. Further details on such a P2P system are disclosed in WO 2005/009019. However, it will also be apparent that the IM system described herein can also use non-P2P communication systems.

0043As mentioned previously, it is advantageous to provide indicators of user activity when a user is typing, in order to improve the user experience and conversation flow. For example, if User A <b>102</b> and User B <b>112</b> in <figref idref="DRAWINGS">FIG. 1</figref> are engaged in an IM conversation, then it is advantageous for User B <b>112</b> to be notified in client <b>118</b> if User A <b>102</b> is typing a message in client <b>110</b> (and vice versa). Reference is now made to <figref idref="DRAWINGS">FIG. 2</figref>, which illustrates a flowchart of a known method for controlling activity notifications in an IM system such as that shown in <figref idref="DRAWINGS">FIG. 1</figref>. In step S<b>202</b> a user (e.g. User A <b>102</b>) initiates an IM conversation with another user (e.g. User B <b>112</b>). A connection across the network <b>106</b> is created in step S<b>204</b>. In preferred embodiments, this connection is a P2P connection.

0044The subsequent steps in <figref idref="DRAWINGS">FIG. 2</figref> are performed independently by each of the clients (e.g. <b>110</b>, <b>118</b>) of the parties engaged in the IM conversation. In step S<b>206</b>, the client monitors whether there is any typing activity at the input field or region of the IM client. Step S<b>206</b> repeats until some activity is detected. When activity is detected, in step S<b>208</b>, the client transmits a message indicating that there is user activity to the other parties in the IM conversation. The other parties, upon receiving the message indicating user activity, display an indicator on the display of the user terminal.

0045In step S<b>210</b>, the client that transmitted the activity notification message in step S<b>208</b> starts a timer running. In step S<b>212</b> the client checks of the timer has expired yet. If not, the client checks if there is any further user activity at the input field of the client in step S<b>214</b>. If there is not further input, then step S<b>212</b> is returned to and the expiry of the timer is checked. If there is further user input, then step S<b>210</b> is returned to, such that the timer is started again from the beginning (i.e. it is reset). If, when control is returned to step S<b>212</b>, it is found that the timer has expired, then the client, in step S<b>216</b>, transmits a message to the other parties indicating that there is no user activity. The other parties, upon receiving this message indicating user inactivity, remove the activity indicator on the display of the user terminal.

0046Therefore, when the method illustrated in <figref idref="DRAWINGS">FIG. 2</figref> is used, there is only an explicit notification that user activity has started, which triggers an activity notification to be displayed The only way in which the activity notification is removed is by the receipt of the inactivity notification message, which is sent if there has been no activity for a predetermined time interval. As mentioned above, this technique does not accurately reflect the user's behaviour, and hence results in the activity indicator being displayed when messages are not actually being typed.

0047<figref idref="DRAWINGS">FIG. 3</figref> illustrates a detailed view of the user terminal (e.g. <b>104</b>) on which is executed client <b>110</b> according to an embodiment of the invention. The user terminal <b>104</b> comprises a central processing unit (“CPU”) <b>302</b>, to which is connected a display <b>304</b> such as a screen, an input device such as a keyboard <b>306</b>, a pointing device such as a mouse <b>308</b>, and optionally a speaker <b>310</b> and a microphone <b>312</b>. The CPU <b>302</b> is connected to a network interface <b>108</b> as shown in <figref idref="DRAWINGS">FIG. 1</figref>.

0048<figref idref="DRAWINGS">FIG. 3</figref> also illustrates an operating system (“OS”) <b>314</b> executed on the CPU <b>302</b>. Running on top of the OS <b>314</b> is the client <b>110</b>. The client <b>110</b> comprises several layers, such as a protocol layer <b>318</b>, a client engine layer <b>320</b> and a client user interface layer (“UI”) <b>322</b>. Each layer is responsible for specific functions. Because each layer usually communicates with two other layers, they are regarded as being arranged in a stack as shown in <figref idref="DRAWINGS">FIG. 3</figref>. The operating system <b>314</b> manages the hardware resources of the computer and handles data being transmitted to and from the network via the network interface <b>108</b>. The client protocol layer <b>318</b> of the client software communicates with the operating system <b>314</b> and manages the network connections over the network <b>106</b>.

0049Processes requiring higher level processing are passed to the client engine layer <b>320</b>, which handles the processing required for the user to have IM conversations over the network <b>106</b>. The client engine <b>320</b> also communicates with the client user interface layer <b>322</b>. The client engine <b>320</b> may be arranged to control the client user interface layer <b>322</b> to present information to the user via the user interface of the client (such as activity indicators) and to receive information from the user via the user interface. In particular, the client engine layer <b>320</b> comprises input analysis functionality <b>324</b>, which analyses inputs made to the client user interface layer <b>322</b> and a look up table (“LUT”) <b>326</b> which contains pre-defined patterns of known inputs. These functions will be described in more detail with reference to <figref idref="DRAWINGS">FIG. 6</figref> below.

0050The client user interface layer <b>322</b> defines the information that is presented to the user <b>102</b> of the user terminal <b>104</b>. Examples of client user interfaces are shown in <figref idref="DRAWINGS">FIGS. 4 and 5</figref>. Reference is first made to <figref idref="DRAWINGS">FIG. 4</figref>, which illustrates the main user interface <b>400</b> of the client <b>110</b> (in this case for User A <b>102</b>), prior to an IM conversation being initiated. The client user interface <b>400</b> displays the username <b>402</b> of User A <b>102</b> in the IM system, and User A can set his own presence state (that will be seen by other users) using a drop down list by selecting icon <b>404</b>.

0051The client user interface <b>400</b> comprises a tab <b>406</b> labelled “contacts”, and when this tab is selected the contacts stored by the user in a contact list are displayed. In the example user interface in <figref idref="DRAWINGS">FIG. 4</figref>, five contacts of other users of the IM system (User B to F) are shown listed in contact list <b>408</b>. Each of these contacts have authorised the user of the client <b>110</b> to view their contact details and online presence and mood message information. Each contact in the contact list has a presence status icon associated with it. For example, the presence status icon for User B <b>410</b> indicates that User B is “online”, the presence icon for User C <b>412</b> indicates that User C is “not available”, the presence icon for User D <b>414</b> indicates that User D's state is “do not disturb”, the presence icon for User E <b>416</b> indicates User E is “away”, and the presence icon for User F <b>418</b> indicates that User F is “offline”. Further presence indications can also be included. Next to the names of the contacts in pane <b>408</b> are the mood messages <b>420</b> of the contacts.

0052An instant message conversation can be initiated with a user listed in contact list <b>408</b> by selecting the contact using pointing device <b>308</b> and clicking on a button that appears adjacent to the name of the user.

0053When an IM conversation is initiated with a user, user interfaces such as those shown in <figref idref="DRAWINGS">FIG. 5</figref> are displayed. In this example, User A <b>102</b> has initiated an IM conversation with User B <b>112</b>. <figref idref="DRAWINGS">FIG. 5A</figref> illustrates the UI displayed on the display of user terminal <b>104</b> of User A <b>102</b>, and <figref idref="DRAWINGS">FIG. 5B</figref> illustrates the UI displayed on the user terminal <b>114</b> of User B <b>112</b>.

0054The UI shown in <figref idref="DRAWINGS">FIG. 5A</figref> comprises a sent message window <b>502</b>, which shows messages from both parties to the IM conversation (i.e. User A and User B) that have already been sent. For example, a previously sent message from User A is shown at <b>504</b> and a previously sent message from User B is shown at <b>506</b>. At the right hand side of the UI is shown the participants in the IM conversation. In this example, a contact card <b>508</b> for User B is shown (as this is the user that User A is communicating with). The contact card <b>508</b> for User B displays User B's name <b>510</b>, presence icon <b>512</b> and avatar <b>514</b>.

0055Above the message window <b>502</b> is a bar that comprises buttons for controlling the IM conversation, which are outside the scope of this description. Below the message window <b>502</b> is a user input field or region <b>518</b>. The user input field is the region of the UI in which messages are composed by the user before they are sent. The user can compose messages in the input field <b>518</b> by placing the cursor in the field and typing using the keyboard <b>306</b>. The user may also place other information in the message, such as icons selected from menu. To send a message that has been composed in the input field <b>518</b>, the user presses the “enter” key on the keyboard or selects button <b>522</b>.

0056Adjacent to the user input field <b>518</b> is a contact card <b>524</b> for the user of the client. In this example, <figref idref="DRAWINGS">FIG. 5A</figref> shows User A's client, and hence User A is shown in contact card <b>524</b>. The contact card <b>524</b> allows the user to set the information that is displayed to the other members of the IM conversation. The contact card <b>524</b> displays User A's name <b>526</b>, presence icon <b>528</b> and avatar <b>530</b>.

0057<figref idref="DRAWINGS">FIG. 5B</figref> illustrates the equivalent UI shown at User B's terminal <b>114</b> (when in conversation with User A). The UI is identical to that shown in <figref idref="DRAWINGS">FIG. 5A</figref>, except that contact card <b>532</b> shows the details for User A (as the UI in <figref idref="DRAWINGS">FIG. 5B</figref> shows the conversation from User B's perspective), and contact card <b>534</b> shows details for User B. Furthermore, a message entered in input field <b>536</b> will obviously result in a message being sent from User B to User A.

0058The UI shown in <figref idref="DRAWINGS">FIGS. 5A and 5B</figref> illustrates a case where there is no activity notification system present, and hence there is no indication in User B's UI in <figref idref="DRAWINGS">FIG. 5B</figref> that User A is typing message, even though a part-typed message is shown in the user input field <b>518</b> of <figref idref="DRAWINGS">FIG. 5A</figref>. Further client UIs shown hereinafter will illustrate the case where activity indicators are employed.

0059Reference is now made to <figref idref="DRAWINGS">FIG. 6</figref>, which illustrates a flowchart for a method of providing activity notifications that accurately reflect user behaviour. In step S<b>602</b> an IM conversation is initiated. For example, referring again to <figref idref="DRAWINGS">FIGS. 1 and 4</figref>, User A <b>102</b> can initiate an IM conversation by selecting the contact for User B <b>112</b> in the contact list <b>408</b> of UI <b>400</b> of client <b>110</b>. In step S<b>604</b> a connection is created over the communication network <b>106</b>. In preferred embodiments, this is a P2P connection.

0060In step S<b>606</b>, the clients of the users connected in the IM conversation (e.g. <b>110</b> and <b>118</b>) monitor the input fields (e.g. input fields <b>518</b> and <b>536</b> of <figref idref="DRAWINGS">FIGS. 5A and 5B</figref>) for any activity by the users. The clients remain in this state until activity is detected. For the purposes of this explanation, it is assumed that User A begins typing a message in input field <b>518</b>, thereby triggering step S<b>606</b>.

0061After activity at the user input field, in step S<b>608</b>, the client analyses the input to the input field in order to detect known patterns in the input. This is achieved by the client UI layer <b>322</b> providing information to the client engine <b>320</b>. The client engine <b>320</b> has analyser functionality <b>324</b> which is arranged to extract pattern information from the user input, and match this to known patterns. The known patterns are stored in look up table <b>326</b>.

0062For example, the input analyser <b>324</b> can analyse several attributes of the inputs entered. These include, but are not limited to: detection of specific keys; repetition of the same keys; the physical grouping of the keys on the keyboard; simultaneous presses of multiple keys; and the number of characters present in the input field.

0063As a first example, the case of a user typing “normal” text in the input field is considered. A “normal” message is a message deliberately types by the user with the intention of sending it to the other party. The input analyser <b>324</b> looks at the sequence of keys entered by the user, and from this determine that they are, for example, comprised of multiple keys (i.e. not all the same key), generally separated physically on the keyboard (i.e. not all from the same region of the keyboard), and separated in time (i.e. not entered simultaneously). From this information, the input analyser can deduce that the user activity is the typing of a normal message. This information can subsequently be used to indicate this type of activity to the remote user (as described in mere detail hereinafter).

0064As a second example, a user may have already typed some text into the input field, but has changed his mind, and started to delete the text. The user can delete the text through repeated presses of the “backspace” or “delete” keys on the keyboard, or by holding down the “backspace” or “delete” keys (which has the same effect as repeated key-presses). The input analyser can detect the use of these specific keys, and when it also detects their repeated use the input analyser can deduce that the user is deleting a message. The input analyser can also detect that a user has highlighted a significant part of a message using the pointing device, and deleted the highlighted part.

0065As a third example, a user may have the IM conversation UI open on his user terminal, but is not intending to send a message at the present time. However, accidental input from the keyboard can occur, e.g. by a foreign object actuating one or more keys of the keyboard (such as a book being accidentally rested on the keyboard or a cat walking over the keyboard). In this case, the input analyser can detect that there is repeated actuation of one or more keys (e.g. due to them being held down by a foreign object) or simultaneous actuation of keys that are grouped together on the keyboard. From this, the input analyser can deduce that the input at the input field is unintentional, and is not the deliberate typing of a message.

0066As a fourth example, the input analyser can be arranged to detect that the user has hit his keyboard in anger or frustration. This can be achieved by detecting the near-simultaneous input of multiple keys all grouped in the same area of the keyboard.

0067As a fifth example, the input analyser can detect the actuation of specific keys. For example, the input analyser can detect that the “enter” key has been pressed, or that the send button <b>522</b> (in <figref idref="DRAWINGS">FIG. 5A</figref>) has been activated. This allows the input analyser to deduce that the message has been completed and is being sent to the other party, and hence that typing has been completed.

0068A sixth example extends the functionality of the second example above. The input analyser can monitor the number of characters that are present in the input field. This can be used to detect that a user has deleted all the characters from a message (i.e. there are zero characters in the input field). This can be used to distinguish between the case where a user has deleted part of a message (e.g. with repeated presses of the backspace key) and when a user has deleted an entire message.

0069It will readily be appreciated that many other types of user activity may also be detected by analysing input patterns, and are not limited to the above examples.

0070In step S<b>610</b>, the client determines whether the analysed input patterns match one of the predetermined input patterns. If the analysed pattern does match a known pattern, then, in step S<b>610</b>, a code is generated to identify the type of activity determined by the input patterns. The codes used are pre-defined, and are stored in LUT <b>326</b>. If the analysed pattern cannot be matched to a known patter, then in step S<b>614</b> a default code is used to represent activity. In preferred embodiments, this code is the same code used to represent normal typing activity.

0071In step S<b>616</b>, the client checks whether the activity type detected matched the previous activity type transmitted to the remote user. If it is a new (i.e. different) type of activity, then in step S<b>618</b> a message is generated and transmitted to the remote user indicating the type of activity that has been detected. If the current activity type matches the previous one sent, then there is no need to send a further activity notification message to the remote user.

0072The structure of the activity notification message <b>700</b> is shown illustrated in <figref idref="DRAWINGS">FIG. 7</figref>. The message <b>700</b> comprises a header <b>702</b>, the username <b>704</b> of the user sending the message (so that the user performing the activity may be identified), and activity code <b>706</b>. In preferred embodiments, the activity code <b>706</b> is in the form of a bitmap, where combinations of bits in the bitmap indicate the different types of activity that can be detected.

0073Steps S<b>620</b> to S<b>628</b> resemble steps S<b>210</b> to S<b>216</b> from <figref idref="DRAWINGS">FIG. 2</figref>, in that they provide a time-out to detect that a user has become idle for a predetermined time period, and that there is no further activity. In step S<b>620</b>, the client starts a timer running, and in step S<b>622</b> the client checks of the timer has expired yet. If not, the client checks if there is any further user activity at the input field of the client in step S<b>624</b>. If there is not further input, then step S<b>622</b> is returned to and the expiry of the timer is checked. If there is further user input, then step S<b>608</b> is returned to, such that the input patterns detected are once again analysed. If, when control is returned to step S<b>622</b>, it is found that the timer has expired, then the client, in step S<b>626</b>, generates the appropriate code to signify user inactivity, and in step S<b>628</b> transmits a message to the other parties indicating that there is no user activity. In preferred embodiments, the message sent at the expiry of the time-out is the same message as shown in <figref idref="DRAWINGS">FIG. 7</figref>, but contains a bitmap that indicates the user has become idle. After step S<b>628</b>, control returns to step S<b>606</b>, and the client awaits further user activity.

0074Note that in some embodiments, S<b>608</b> can include an initial check to determine if the user has started to enter information into a user input field which was previously empty. In this instance, the input analyser can make an initial assumption from the very first key-press that this corresponds to normal typing, and in response to this sends an activity notification indicating the user is typing. This ensures that the remote user is initially displayed a typing indicator as a default setting, in order to give an indication of user activity to the remote user as soon as possible after typing begins. However, as the number of key-presses at the input field increases, the input analyser can perform further processing on this information and further deduce information about the user activity, and subsequently send further notification messages to update the activity indicator at the remote user if required.

0075Reference is now made to <figref idref="DRAWINGS">FIG. 8</figref>, which illustrates a flowchart of the process performed at the client of a user that has received an activity notification message <b>700</b>.

0076In step S<b>802</b>, the activity notification message (such as that shown in <figref idref="DRAWINGS">FIG. 7</figref>) is received at the client. The information from the message is passed to the client engine layer <b>320</b> to be processed. In step S<b>804</b>, the type of activity is determined from the activity code <b>706</b> in the message <b>700</b>. This is achieved by using the LUT <b>326</b> to match the activity code to the type of activity.

0077In step S<b>806</b>, the current state of the activity indicator in the UI of the client is determined. For example, it can be determined whether there is currently an activity indicator present, and, if so, what type of activity it is indicating. In step S<b>808</b> the action that needs to be taken in response to the activity notification message is determined. More specifically, the client must decide whether or not to change the current state of the activity notification to a different state. In particular, as shown in step S<b>810</b>, there are three possible outcomes for the action to be taken. Either the current activity indicator can be removed (S<b>812</b>), the current activity indicator can be replaced with a different type of indicator (S<b>814</b>) or the current activity indicator can be maintained in its current state (S<b>816</b>).

0078Examples of the operation of the flowcharts shown in <figref idref="DRAWINGS">FIGS. 6 and 8</figref> are now described with reference to <figref idref="DRAWINGS">FIGS. 9 to 13</figref>, which illustrate the effect of the processes on the UI of the client in several example scenarios.

0079Reference is first made to <figref idref="DRAWINGS">FIGS. 9A and 9B</figref>, which illustrate a similar scenario to that illustrated in <figref idref="DRAWINGS">FIGS. 5A and 5B</figref> above. <figref idref="DRAWINGS">FIG. 9A</figref> shows the client UI for User A <b>102</b>, who has initiated an IM conversation with User B <b>112</b>. The information displayed in the UI shown in <figref idref="DRAWINGS">FIG. 9A</figref> is identical to that shown in <figref idref="DRAWINGS">FIG. 5A</figref>. In this example, User A has partly-typed a message into input field <b>518</b>. As a result of User A <b>102</b> typing this message, the client <b>110</b> executed on User A's terminal <b>104</b> has analysed the input patterns, and determined that this corresponds to normal typing. This has been encoded into an activity notification message <b>700</b> (see <figref idref="DRAWINGS">FIG. 7</figref>), and transmitted to User B <b>112</b> (the other participant in the IM conversation).

0080<figref idref="DRAWINGS">FIG. 9B</figref> illustrates the UI of the client for User B <b>112</b>, following the reception of the activity notification message. Prior to receiving the activity notification message, the client showed no activity indicator (as in <figref idref="DRAWINGS">FIG. 5B</figref>). The client <b>118</b> of User B <b>112</b> has determined from the activity notification message that User A's activity corresponds to normal typing. The client <b>118</b> has therefore determined that an indicator needs to be placed in the UI indicating typing by User A. The typing activity indicator <b>902</b> is shown in User A's contact card <b>532</b>. In the example shown in <figref idref="DRAWINGS">FIG. 9B</figref>, the typing activity indicator is in the form of a pencil icon. This is shown enlarged at <b>904</b> for clarity. Any other suitable form of indicator could also be used, such as a written indication instead of an icon. In preferred embodiments, the pencil icon <b>902</b> is animated.

0081The pencil icon <b>902</b> remains on the UI of User B's client, indicating that User A is typing, until a further activity notification message is received. For example, if User A <b>102</b> completed the message and pressed “enter” or button <b>522</b>, then a further activity notification message would be sent with a code indicating that the message was completed. This would prompt User B's client <b>118</b> to remove the pencil icon <b>902</b> from the UI. Similarly, if User A <b>102</b> stopped typing, such that the timer at step S<b>620</b> in <figref idref="DRAWINGS">FIG. 6</figref> expired, then an activity notification message is sent to User B's client <b>118</b>, and the pencil icon <b>902</b> is removed or replaced with another icon to indicate that User A <b>102</b> has become idle.

0082Reference is now made to <figref idref="DRAWINGS">FIGS. 10A and 10B</figref>, which illustrate the scenario in which User A was typing a message in the input field <b>518</b>, but has changed his mind and has deleted almost all of the message. Prior to detecting the repeated deletion of characters, the client <b>110</b> of User A will have detected the typing of the (now deleted) message, and sent an activity notification message to the client <b>118</b> of User B. This will have prompted the client of User B to show the typing indicator as illustrated in <figref idref="DRAWINGS">FIG. 9B</figref>. However, User A <b>102</b> has now deleted most of the unsent message. The deletion is detected by the input analyser, and an activity notification message <b>700</b> is generated by the client of User A including the code for the activity of deletion.

0083The effect of the receipt of this activity notification message on the UI of User B is shown in <figref idref="DRAWINGS">FIG. 10B</figref>. As mentioned, this UI previously showed the pencil icon <b>902</b>. However, following the notification that User A is deleting a message, the icon has been replaced. In this example, the icon is again a pencil <b>1002</b>, but the pencil has been inverted so that it is shown using an eraser mounted on the end of the pencil as opposed to writing (shown enlarged at <b>1004</b> for clarity). In preferred embodiments, this icon is animated. In alternative embodiments, the indication could use text rather than an icon, or any other suitable form of indication.

0084Furthermore, referring again to <figref idref="DRAWINGS">FIG. 10A</figref>, when all of the characters have been deleted from input field <b>518</b>, a further activity notification message <b>700</b> can be sent to User B. This message informs User B's client that the message has been completely deleted. This information is used by User B's client <b>118</b> to change the activity notification. For example, the client <b>118</b> could remove the erasing notification and show no icon (thereby indicating no activity). Alternatively a different icon could be used.

0085Reference is now made to <figref idref="DRAWINGS">FIGS. 11A and 11B</figref>, which illustrate a further type of user activity being detected. In <figref idref="DRAWINGS">FIG. 11A</figref>, User A has hit his keyboard in frustration. This has resulted in a set of characters being entered into the input field <b>518</b> that are characterised by being grouped together on the keyboard, and were also entered near-simultaneously. This is analysed by the input analyser, which deduces the user behaviour and transmits a message to User B containing the appropriate code.

0086The result of receiving the activity notification message with this code is shown in <figref idref="DRAWINGS">FIG. 11B</figref>. In this example, the activity indicator is shown as an angry face <b>1102</b> (enlarged at <b>1104</b> for clarity). This indicator therefore attempts to communicate the emotions of User A to User B by interpreting the inputs entered by User A.

0087Reference is now made to <figref idref="DRAWINGS">FIGS. 12A and 12B</figref>, which illustrate a scenario in which the input detected at the input field is detected as an unintentional input by the user. <figref idref="DRAWINGS">FIG. 12A</figref> illustrates the client for User A, and in this exemplary scenario User A has accidentally left an item against the “0” key of the keyboard, thereby giving rise to a string of zeroes entered into it being rapidly entered into the input field. This is detected by the input analyser, and interpreted as an accidental input. This information is converted to a code and transmitted in an activity notification message. This is reflected in the UI of User B, which reads the activity type code and determines that the appropriate action to take is to remove any pre-existing activity indicator, so that region <b>1202</b> of the UI shows no activity. The ability to transmit a message and remove an activity indicator in response thereto is an important function, as the first few entered characters of an accidental input may trigger a “normal” typing message to be sent thereby giving the remote user the impression that a message is being typed. However, by sending a further message once it is determined that the input is accidental allows the typing indicator to be rapidly cleared from the remotes user's UI.

0088Reference is now made to <figref idref="DRAWINGS">FIG. 13</figref>, which illustrates the use of activity indicators in a multichat scenario. A multichat is an IM conversation in which there are more than two participants. The above-described techniques allow activity notifications to be provided for every member of the IM conversation. The UI shown in <figref idref="DRAWINGS">FIG. 13</figref> shows the client <b>118</b> for User B, who is engaged in an IM conversation with User A <b>102</b>, User C <b>120</b> and User D <b>122</b>. Previous messages sent in the IM conversation are shown at <b>1302</b>. Contact cards are shown for Users A, C and D at <b>1304</b>, <b>1306</b> and <b>1308</b> respectively. The client <b>118</b> for User B has, in this example, received activity notification messages from User A's client <b>110</b> and User D's client <b>130</b>, indicating that these users are typing (it will be recalled that the activity notification messages <b>700</b> contain a field for the username <b>704</b> to allow the receiving client to identify the user to which the message relates). This activity is indicated by activity indicators <b>1310</b> for User A and <b>1312</b> for User D.

0089While this invention has been particularly shown and described with reference to preferred embodiments, it will be understood to those skilled in the art that various changes in form and detail may be made without departing from the scope of the invention as defined by the appendant claims. For example, the preceding example embodiments have described the use of a keyboard for providing input to the IM system. It will be understood that any suitable form of input device could also be used, such as handwriting recognition, input controlled by a pointing device or stylus, a touch-screen, or a numeric keypad.