WO2005125153A1

WO2005125153A1 - Method and system for regulating on-line services

Info

Publication number: WO2005125153A1
Application number: PCT/GB2005/002258
Authority: WO
Inventors: Jeffrey Roger Farr; Ben Strulo
Original assignee: British Telecommunications Public Limited Company
Priority date: 2004-06-17
Filing date: 2005-06-09
Publication date: 2005-12-29
Also published as: GB0413620D0

Abstract

The present invention addresses the above problem by providing a method and system for regulating on-line services by providing for the receipt of input from users of the service relating to the behaviour of a first user with respect to a second user. The first user's use of the on-line service may then be modified in dependence upon the input, the modification preferably being selectively applied in dependence upon the use of the on-line service by the second user. For example, in a message based application such as a chat-room, the first user may be delayed from posting messages to the chat-room for a certain time period after the second user has posted a message, but is not delayed from posting messages in response to messages posted by other users. The modification of the service in dependence on the input from other users allows other users to rate the relationship between the first and second users, and for appropriate regulatory action to be taken in dependence on the ratings. The preferable selective application of the modification allows for the regulatory action to be taken only when required, and for the first user's other use of the service to remain unaffected.

Description

Method and System for Regulating On-line Services

Technical Field The present invention relates to a method and system for regulating the use of online services, for example such as chat-rooms or other fora. More particularly, the invention provides a method and system for regulating a first user's use of such services in dependence on information relating to his behaviour towards another user, and received from other users. Background to the Invention and Prior Art Online fora such as Internet chat rooms, newsgroups and the like are well known in the art. They typically take the form of a communications interchange in which users may communicate through successive electronic transmissions between respective computer systems. Figure 2 illustrates a typical system architecture which facilitates such online fora. Referring to Figure 2, a server computer 20 is provided, which has a network connection to a network, or collection of interconnected networks, such as the Internet 21. This server computer 20 is provided with a computer readable storage medium 202, upon which is stored a chat room program 210. The chat room program 210, when executed by the server computer 20, provides a chat room application for use by client programs running on various user computers, which are arranged to communicate with the server computer 20 via logical connections formed over the network 21. For example, user computers 22, 24, 26, and 28 are respectively provided with client programs 222, 242, 262, and 282. The respective client programs are commonly browser type programs, such as Microsoft Internet Explorer ™, or Netscape Navigator™. The client programs respectively running on each user computer communicate with the chat room program 210 running on the server computer by suitable logical connections over the network 21 , and usually TCP/IP connections when the network is the Internet. Figure 1 illustrates an example prior art chat room application as is generally known in the art, as would be displayed to each user by their respective client computer programs. More particularly, each client computer program causes a window 1 to be

-displayed to the user, which contains a first display portion 2, and a second display portion

3. Within the first display portion two is displayed a graphical display for illustrating various message threads, of messages which have been posted to the server computer 20 by various client users. Additionally displayed is information 5 giving the identity of each user who has posted each message, as well as further information 6 giving the date when each message was posted to the chat room application at the server computer 20. The individual messages themselves are displayed in the display portion 3, as individual messages 7. A user interface (not shown) will typically be provided to allow a user to control the chat room application, so as to perform the usual functions provided thereby, such as selecting message threads for display, and sending messages to particular selected threads. Whilst such online fora as described above can be considered generally beneficial in that they provide for interested users to discuss topics of interest, unfortunately in some cases such fora also give users the opportunity to publicly insult, humiliate, or otherwise denigrate others of the users. The practice of sending insulting messages to online fora such as chat rooms or the like is known as "flaming" and can represent a significant problem in that the language used may offend users, as well as the content of "flaming" messages detracting from the overall utility of the particular chat room or newsgroup. In order to discourage such behaviour, in the past it has been the practice of members of chat rooms to post their own "flaming" messages in response to the original offending message, in an effort to publicly humiliate the originally offending user and hence discourage further misbehaviour. Other, more systematic, techniques are also known in the art, such as that described in EP0983540, which provides a method by which user members of a chat room or similar application may cast a vote against another user who they feel has sent disruptive or offending messages. The practice of such voting is referred to in EP0983540 as "eviling" and for each user registered with the chat room service an "evil index" is stored, which registers the number of "evil" votes cast against that user by other users. A basic penalty for having a non-normal "evil index" is described as being denial of access to a particular forum, or the online service until the users "evil index" has decayed back to normal. In a more refined embodiment, a users "evil index" affects a rate limit which governs a user's ability to send (and/or receive) messages. Such a feature is described as allowing other participants to "evil" a user who "flames" or "spams" them, and thus reduce the rate at which the recalcitrant user can send and/or receive messages. Whilst such a system provides for systematic sanctions to be applied against a recalcitrant user who has been "evilled" by other users of the online service, the penalty measures are applied uniformly across the entire usage of the service made by the recalcitrant user i.e. the user is prevented from accessing the service at all, or is rate limited as to the number of messages he may send to the service. However, such global penalties applied to the entire use of the service do not accurately reflect what is in reality a complex social community embodied by the forum or newsgroup. Within such communities it may be that a particular offending user is only offensive to one or two other users (so called "adversary" users herein), but in general provides an overall net contribution to the utility of the newsgroup or chat room by otherwise providing useful messages. A regulatory mechanism which therefore deters and punishes only the disruptive behaviours, whilst placing no barriers whatsoever to a user's positive contributions is therefore desirable.

Summary of the Invention The present invention addresses the above problem by providing a method and system for regulating on-line services by providing for the receipt of input from users of the service relating to the behaviour of a first user with respect to a second user. The first user's use of the on-line service is then modified in dependence upon the input, the modification preferably being selectively applied in dependence upon the use of the online service by the second user. For example, in a message based application such as a chat-room, the first user may be delayed from posting messages to the chat-room for a certain time period after the second user has posted a message, but is not delayed from posting messages in response to messages posted by other users. The modification of the service in dependence on the input from other users allows other users to rate the relationship between the first and second users, and for appropriate regulatory action to be taken in dependence on the ratings. The preferable selective application of the modification allows for the regulatory action to be taken only when required, and for the first user's other use of the service to remain unaffected. In view of the above, from a first aspect the present invention provides a method of regulating the use of an on-line service, comprising the steps of: a) receiving input about a first user's use of the on-line service with respect to at least a second user from one or more other users; and b) modifying the first user's ability to use the on-line service in dependence upon the received input. In the first aspect the advantage is provided that other user's of the on-line service are able to provided information regarding the first user's relationship to a second user, thus allowing the other users to effectively "rate" that relationship. Modification of the first user's use of the on-line service is then undertaken in response to this input, which ensures that modification is applied when necessary as identified by other users. Such operation prevents two antagonistic users from respectively "warring" with each other either through sending respective "flaming" messages backwards and forwards or by voting for each other to be regulated. Preferably, the modifying is selectively applied dependent upon use of the on-line service by the second user. This ensures that regulation is only applied to the first user's use only when necessary, thus allowing the user to post other messages which may have an overall net utility to the service. Moreover, preferably the modifying is selectively applied after use of the on-line service by the second user. Thus regulation of the first user's use of the service is directly dependent on use of the service by the second user, thus further targeting the conditions upon which modification is applied. In preferred embodiments the online service is a message based service wherein users post messages to the service which may then be viewed by other users, and wherein the first user's ability to use the service is modified after the second user has posted a message to the service. Thus the invention is particularly, although not exclusively, applicable to on-line fora such as chat rooms, newsgroups or the like. In preferred embodiments the modifying step comprises delaying the first user's use of the on-line service. Such use may be delayed by a predefined time period, or alternatively, and preferably, by a time period calculated as a function of the received input. Preferably the function relates the time period to the number of input messages received relating the first user and the second user. In alternative embodiments the first user's use of the service is delayed until a number of further messages have been posted to the on-line service. The number of further messages may be calculated as a function of the received input, or alternatively may be predefined. Where calculated as a function of the inputs, preferably the function relates the number of further message to the number of input messages received relating the first user and the second user. By delaying use by a number of messages rather than a time period the delay sanction is directly coupled to other users of the service, and so for less well-populated services the delay may be longer. For well populated services, however, the delay imposed may end up being very short. In preferred embodiments preferably the modifying is dependent on the time since the input was received, such that the first user's use is modified less with respect to time since the input receipt. This allows for the regulation of the first user's use to "decay" with time, such that if the user behaves and no further input is received from other users then eventually no modification will be applied to his use of the service. From a second aspect the invention provides a system for regulating the use of an on-line service, comprising: a) means for receiving input about a first user's use of the on-line service with respect to at least a second user from one or more other users; and b) service control means arranged in use to modify the first user's ability to use the on-line service in dependence upon the received input. Within the second aspect the same advantages and further features and advantages are provided as in the first aspect, mutatis mutandis. In another aspect the present invention also provides a method of regulating the use of an on-line service, comprising the steps of: a) receiving input about a first user's use of the on-line service from other users; and b) delaying the first user's use of the on-line service in dependence on the received input. Within this further aspect the ability of the user to use the service is modified by delaying his use of the service in dependence on the received input, whereby each use attempt is delayed, but preferably the number of use attempts in any particular period is not limited. Thus, for example, where the on-line service is a message based service, the ability of the user to post messages to the service may be delayed, although the number of messages which may be sent is not limited: the delay is applied to each message. Such use may be delayed by a predefined time period, or alternatively, and preferably, by a time period calculated as a function of the received input. Preferably the function relates the time period to the number of input messages received relating the first user and the second user. In alternative embodiments the first user's use of the service is delayed until a number of further messages have been posted to the on-line service. The number of further messages may be calculated as a function of the received input, or alternatively may be predefined. Where calculated as a function of the inputs, preferably the function relates the number of further message to the number of input messages received relating the first user and the second user. By delaying use by a number of messages rather than a time period the delay sanction is directly coupled to other users of the service, and so for less well-populated services the delay may be longer. For well populated services, however, the delay imposed may end up being very short. From another aspect the invention provides a system for regulating the use of an on-line service, comprising: a) means for receiving input about a first user's use of the on-line service from one or more other users; and b) service control means arranged in use to delay the first user's use of the online service in dependence upon the received input. Within this aspect the same advantages and further features and advantages are provided as in the previous aspect, mutatis mutandis. From a further aspect there is further provided a computer program or suite of computer programs arranged such that when executed by a computer it/they cause(s) the computer to perform a method of the first or third aspects. The computer program or programs may in some circumstances be embodied by a modulated carrier signal incorporating data corresponding to the computer program or at least one of the suite of programs, for example a signal being carried over a network such as the Internet. Moreover, from a sixth aspect the invention also provides a computer readable storage medium storing a computer program according to the fifth aspect. The computer readable storage medium may be any magnetic, optical, magneto-optical, solid-state, or other storage medium capable of being read by a computer.

Brief Description of the Drawings Further features and advantages will become apparent from the following description of embodiments thereof, presented by way of example only, and by reference to the accompanying drawings, wherein like reference numerals refer to like parts, and wherein:- Figure 1 is an illustration of an example chat room application generally known in the art; Figure 2 is a diagram illustrating the operating environment of some embodiments of the present invention; Figure 3 is a flow diagram illustrating the overall operation of an embodiment of the present invention; Figure 4 is a block diagram illustrating message flows between modules in an embodiment of the present invention; Figure 5 is a flow diagram illustrating the operation of a particular module used in an embodiment of the present invention; Figure 6 is a table illustrating data stored by a module in an embodiment of the invention; Figure 7 is a message format diagram illustrating a message format used in an embodiment of the present invention; Figure 8 is a message format diagram illustrating a message format used in an embodiment of the present invention; Figure 9 is a flow diagram illustrating the operation of a module used in an embodiment of the present invention; Figure 10 is a table illustrating data stored in a module used in an embodiment of the present invention; Figure 11 is a graph illustrating particular functions which may be used by a module in an embodiment of the present invention; Figure 12 is a graph illustrating particular functions which may be used by a module in an embodiment of the present invention; Figure 13 is a drawing illustrating the output of a chat room application in accordance with an embodiment of the present invention; Figure 14 is a drawing illustrating the output of a chat room application in accordance with an embodiment of the present invention; and Figure 15 is a drawing illustrating the output of a chat room application in accordance with an embodiment of the present invention.

DESCRIPTION OF THE EMBODIMENTS Embodiments of the present invention will now be described with respect to Figures 2 to 15. Referring first to Figure 2, this illustrates the general operating environment of embodiments of the present invention. The present invention is aimed at regulating an online service such as, for example, chat rooms or newsgroups or the like, and as such is intended primarily to be implemented in software which is run in conjunction with the online service at a server computer or the like. As in the prior art described in the introduction, a server computer 20 is arranged to communicate over logical connections provided by a network 21 , with user computers 22, 24, 26, and 28, each of which are running appropriate client programs 222, 242, 262, 282, such as a web browser program or the like. Each client program is arranged to display the output of the online service to its respective user, and to accept messages to be sent, and commands, etc, therefrom. Within the embodiments of the invention to be described, the server computer 20, being provided with a computer readable storage medium 202, such as a hard disk drive, DVD drive, or the like, has stored on the computer readable storage medium a chat room program 210 (where the online service being provided is a chat room - where other services are being provided such as newsgroups, or the like, then there will be an appropriate program stored in place of the chat room program 210), which is arranged when executed to control the server computer 20 to provide the usual chat room services associated with Internet chat rooms. Such services include the ability to receive messages from users, and to display the messages in the list to other users. Additionally provided by the embodiments are a message analyser program 204, a user behaviour program 206, and an overall control program 208. The control program 208 is arranged to control the operation of the chat room program 210, the message analyser program 204, and the user behaviour program 206 with respect to each other to provide the online service. The operation of the message analyser program 204, the user behaviour program 206, and the control program 208 will be described in detail below. Figure 3 is a flow diagram which illustrates the overall operation of the described embodiments, as administered by the control program 208. With reference to Figure 3, where the server computer 20 running the control program 208 is providing a chat room service as the online service, at step 3.2 a user is required to register with the chat room prior to being able to post messages thereto, or view messages already on the service. Whenever a user registers with the chat room, then at step 3.4 the control program 208 controls the user behaviour program 206 to instantiate a user behaviour module for the user. The user behaviour module stores an "adversary list" for that user, which is a table of data values indicating the perceived relationship of that user with other registered users, as perceived by other users of the service. In addition, each user behaviour module also stores other useful specific data defining functions, look up tables, or the like, which relate the data values stored in the adversary list to a delay which should be applied to that user's messages, when that user posts a message to the online service. Further details of the operation of a user behaviour module are given later. Returning to Figure 3, following step 3.4, once the user behaviour module has been instantiated for the registered user, then a wait state at step 3.6 is entered, wherein no further processing is performed until one of either two events has occurred. The first such event which may occur is that the user may post a message to the chat room, at step 3.8. Here, the message is posted from the client program running on the user computer, and is passed via a logical connection over the network to the web server computer 20, and received by processes under the control of the control program 208. The control program 208 then buffers the received message, and accesses the chat room program 210 to determine which other registered users have recently posted messages to the chat room. This information is then passed by the control program 208 to the user behaviour module instantiated for the user from which the message was received, and which operates in accordance with the user behaviour program 206. The user behaviour module uses the user information passed to it from the control program 208 to check the user's adversary list, to determine whether any of the users who have recently posted messages to the chat room are on the particular user's adversary list. If so, then the user behaviour module determines a time delay to be applied to the posting user's message, as will be described later. The determined time delay is then passed back to the control program 208. At the control program 208, the buffered message is delayed by an amount of time determined by the time delay, and after the time delay has occurred it is passed to the chat room program 210, for display on the chat room message board, at step 3.12. Each chat room 210 then displays the received message in the normal manner. At this point, therefore, the message received from the user has been posted to the chat room, and displayed to the other users, but subject to any time delay determined by the user behaviour module. The next step to be performed is therefore that provision must be made for other users to be able to object to the posted message, and this is provided by instantiating a message analyser module for the particular message, at step 3.14. Thus, the control program 208 controls the message analyser program 204 to instantiate a message analyser module for the posted message, which message analyser module then operates in accordance with the message analyser program 204. The message analyser module initially performs no function other than to monitor for objections to the message in respect of which it has been instantiated, at step 3.16. Thus, whilst an instantiated message analyser module is monitoring for objections, the system enters the wait state 3.6. From the wait state at step 3.6, let us now assume that an objection message is received at step 3.22. The format of an objection message will be described later. Having received an objection message at the server computer 20, the control program 208 routes the received message to the appropriate message analyser module which was instantiated in respect of the message for which the objection has been received. At the identified message analyser module, the objection message is parsed and aggregate objection data updated in accordance with the received objection data, in a manner to be described later. Aggregate objection data is then output to the user behaviour module for the user who posted the message in respect of which the identified message analyser module was instantiated, at step 3.20. The format of the aggregate objection data output to the user behaviour module will be described later. At the user behaviour module, the aggregate objection data is received, and is used to update the adversary list, at step 3.18. The updating of the adversary list will be described later. Following the updating of the adversary list, the user behaviour module re enters the wait state at step 3.6. Similarly, the message analyser module also re-enters the wait state at step 3.6 to await further objections to the message. Following from the above description, therefore, it should be understood that for each user registered with the online service a user behaviour module is instantiated, which operates under the control of the user behaviour program 206. Moreover, for each message which a registered user posts to the online service, a message analyser module is instantiated, which is operated under the control of the message analyser program 204. When an objection is received from other users in respect of a particular message, it is routed to the message analyser module instantiated specifically for that message, wherein objection data is aggregated, and then output to the user behaviour module for the user who posted the message. At the user behaviour module objection data from each message analyser module relating to messages posted by the user to which the user behaviour module relates are further aggregated, and a time delay to be applied to messages from that user determined in dependence thereon. An example of this operation is shown in Figure 4. With reference to Figure 4, a first user behaviour module 42 has been instantiated in respect of the registered user "Ann", and a second user behaviour module 44 has also been instantiated in respect of the registered user "Ben". "Ann" has posted at least three messages to the online service, and hence at least three message analyser modules 422, 424, and 426 have been instantiated respectively in respect of those posted messages. Similarly, user "Ben" has posted two messages to the online service, and as a result message analyser modules 442, and 444 have been respectively instantiated in respect thereof. In this example, of the messages posted by the users "Ann" and "Ben", some of these messages have received objections from other users. More particularly, message ID No. 70192 to which message analyser module 422 relates has been objected to four times, and four objection messages have been received at the message analyser module 422. Each time an objection message is received, the message analyser module 422 parses the message, and aggregates objection data to keep a track of the number of objections which have been received. This aggregate objection data is then passed to the user behaviour module 42, which relates to the user "Ann". Similarly, message analyser module 426 which relates to message ID No. 70257, has received two objections. These objections are then used to update the aggregate objection data stored in the message analyser module 426, and this aggregate objection data is forwarded to the user behaviour module 42. At the user behaviour module 42 all received objection data from each message analyser module 422, 424, and 426, is further aggregated, and used to determine a time delay which is applied to the user "Ann's" messages. Similar to the above, in respect of the user "Ben" message analyser module 444 which relates to message ID No. 70223 has received an objection, and this objection is used to update aggregate objection data at the message analyser module, which is then forwarded to the user behaviour module 44. The user behaviour module 44 further aggregates all objection data received from each message analyser module which relates to messages posted by the user "Ben", and may be used to determine a time delay to be applied to messages by the user "Ben". Further details of the operation of a message analyser module and a user behaviour module will be described next. Referring to Figure 5, this illustrates the steps performed by a message analyser module during the operation of the described embodiments. As described previously, when a message is posted to the chat room (by passing from the control program 208 to the chat room program 210) then a message analyser module is instantiated for that message, and which is controlled by the message analyser program 204. Therefore, in Figure 5 at step 5.2 a message analyser module is instantiated, such that step 5.2 can be considered to be identical to step 3.14 described previously. The purpose of the instantiated message analyser module is to receive objections concerning the message from other users of the online service, and hence at step 5.4 the message analyser module waits to receive any objections. As described previously, objections are sent by users via their respective clients programs, over logical network connections to the web server computer 20, and are passed to the control program 208 which then routes the objection message to the appropriate message analyser module in dependence on the message ID to which the objection relates. The format of an objection message is shown in Figure 7 and described next. An objection message 70 comprises several fields including a message ID field 72 which identifies the posted message to which the objection relates. Thus, given the example chat room application Figure 1 , the message ID Field 72 will contain data indicating one of the messages 1 to 14 which are presently live within the chat room. The next field is the objection rating field 74, which contains a preferably scalar value indicating the degree to which the message is objected to. In the embodiments described herein no use is made of this value, but in future, more refined embodiments, such use may be made. The next field is a target ID field, and this contains the user ID of a user which the sender of the objection (being another user of the online service) believes the objected message identified in the message ID field 72 is targeted at. Thus, for example, within Figure 1 message 7 ("Dave, you are a complete no brain loser!") appears to be targeted at the user "Dave", and hence an objection sent in respect of this message would indicate "message 7" in the message ID field 72, and the user "Dave" in the target ID field 76. The next field is a free text comment field 78, which contains free text data to enable the sender of the objection to comment on the message. Again no use is made of this field in the embodiments described herein, but in future more refined embodiments such use may be made. Finally, the field 79 contains the user ID of the user who has sent the objection. Returning to Figure 5, and given the above described objection message format, assuming that an objection message has been received at step 5.6, and routed to the appropriate message analyser module by the control program 208, at step 5.8 the message analyser module parses the received objection message, applying the above described format to determine the message content. Then, at step 5.10 the received data is used to update an objection table, which stores aggregate data indicating at which other user the message is perceived to be targeted at, by other users of the online service. An example objection table is shown in Figure 6. With reference to Figure 6, it will be seen that an objection table comprises a column of user ID'S 62, which contain entries for each user ID which has been identified in the target ID field 76 of a received objection message. In the example shown in Figure 6, five users ID's have been indicated (James_32, Clive46, Jennifer_01 , Roger_99, and Simon_02), as well as one "group" ID. The "group" user ID may be included in the targetJD field 76 of an objection message when the sender of the objection message believes that the message is intended to target not one specific user, but is aimed at the group as a whole. The next column, 64, comprises an aggregate count of the number of objection messages received which indicate the particular user ID within the target ID field 76. Thus, for example, eight objection messages have been received which indicate "group" in the targetJD field 76, whereas only two objection messages have been received which believed that the target of the objected to message was user James_32. These aggregate counts are then represented as percentages in the next column 66, each value being taken as the percentage of the total number of objection messages received, being the sum of the values in column 64. Returning to Figure 5, at step 5.10 the objection table is updated by incrementing the number in column 64 corresponding to the user ID contained in the target ID field 76 of the received objection message, and then the percentage values in column 66 are recalculated. If the user ID contained within the targetJD field 76 of the received objection message is a new user ID in that it is not contained within column 62 of the objection table, then a new row is added to the objection table, adding the received user ID, together with the appropriate values (a value of 1 in column 64) in column 64 and 66. Once the objection table has been updated, processing then proceeds to step 5.12 wherein the message analyser module outputs the objection table data to the appropriate user behaviour module. Figure 8 illustrates a message format by which the objection table data may be output. More particularly, with reference to Figure 8, objection table data 80 comprises a first field 82 containing the percentage value corresponding to the "group" user ID taken from column 66 of the objection table. Next, a second field 84 contains data indicative of the percentage value corresponding to the next user ID in column 62, and then further fields are also incorporated within the data 80 for each user ID contained within the column 62. Thus, for each user ID contained within column 62, the corresponding percentage value from column 66 is included as a field in the objection table data 80, together with the user ID to which it relates. Finally, the objection table data 80 is completed with a time stamp field 88, which contains a time stamp indicating the time and date at which the message to which the message analyser module relates was posted to the online service. Once the objection table data has been output to the user behaviour module, the message analyser module returns to the wait state at step 5.4, to wait for further objections. From the above it will therefore be understood that each message analyser module receives objection messages, and then updates an objection table in response to the receipt of an objection message. Whenever the objection table is updated the objection table data is output to the corresponding user behaviour module for use thereby. The operation of a user behaviour module will now be described with respect to Figures 9 to 12. As mentioned previously, a user behaviour module is instantiated for every registered user of the online service, and each user behaviour module operates under the control of the user behaviour program to perform two functions. The first function is to maintain an "adversary table" which is a list of user ID's of users of the online service, together with an indication of the extent to which other users of the service believe the present user (in respect of which the present user behaviour module relates) exchanges "flame" messages with each user identified in the list. The data indicating the extent to which the other user is in "conflict" (i.e. exchanges "flame messages or the like) with another user is determined upon the received objection messages. The second function performed by a user behaviour module is to determine how the user's use of the online service is to be modified. Within the present embodiments described herein the modification is in the form of a time delay applied to the user's message before they are posted to the online service such as the online chat room 210. This time delay, or more generally modification, is determined in dependence upon the data stored in the adversary table. These two facets of the operation of a user behaviour module will now be described in more detail with respect to Figure 9. In Figure 9, at step 9.2 a user behaviour module is instantiated for a user, when that user registers with the online service. As described previously, the control program 208 handles the registration process, and then controls the user behaviour program 206 to instantiate the user behaviour module for the newly registered user. Each user behaviour module then enters a wait state at step 9.4, which is exited when either of two occurrences happen. The first occurrence which causes the wait state to be exited is that objection table data is received at step 9.6 from a message analyser module. As described previously, the objection table data constitutes a sequence of user ID's and percentage values indicating the percentage of objection messages which have been received at the particular sending message analyser module which identify the user ID as the target of the message. Once such objection table data is received, at step 9.8 the user behaviour module parses the data to determine the individual user ID's and percentage values. Then, at step 9.10 the user behaviour module updates its adversary table with the received data, in accordance with the following. Figure 10 illustrates an example adversary table provided by an embodiment of the invention. Here it will be seen that the table comprises two columns, a first column 102 containing the user ID of other users of the online service, and the second column 104 containing percentage values indicating the degree to which each user identified in column 102 can be considered an "adversary" of the user to which the user behaviour module relates. The percentage values contained in column 104 are calculated from the objection table data received from the message analyser modules, as follows. Where a user ID received within the objection table data already exists within the adversary table, then the percentage value for that user ID is updated in accordance with the following equation:-

, _{rr r} (Adv _ value _ old[User _ID])n + Received _ value[User_ ID]

Adv _ value _ new\User _ ID] = n + \ Where Adv_value_new[User_ID] is the updated percentage value for the user with userJD, Adv_value_old[user_ID] is the existing percentage value in the table for the user with userJD, received_value[user_ID] is the percentage value corresponding to the userJD received in the objection table data, and π is a counter of the number of sets of objection table data already received (excluding the newly received objection table data). The above equation is applied to calculate a new percentage value for every existing user ID in the user ID column 102 which is identified in the received set of objection table data. However, where no data is received for an existing particular user ID in a received set of objection table data, then the following equation is used instead to update the percentage value for those users:-

(Adv _ value _ old[User _ ID])n Adv _ value _ newUser _ ID] = - n + 1

In order to process the received values in accordance with the above equations, the user behaviour module maintains a counter n of the number of sets of objection table data which it receives from message analyser modules. Where the received objection table data contains a user ID which is not presently in the adversary table, then the user ID is added to the adversary table at column 102, and the corresponding percentage value is calculated in accordance with the following equation:-

Re ceived _ value[User _ ID] Adv _ value _ new User _ ID] = - n + l Using the above three equations, the adversary table may be updated to accommodate any new sets of objection table data which it receives from message analyser modules. Once a user behaviour module has updated its adversary table at step 9.10, it then re-enters the wait state at step 9.4, waiting either for further objection table data to be received, or instead to receive a query from the control program 208 as to whether or not the control program 208 should modify the user's use of the online service (the user here being the user to which the user behaviour module relates). Such a query will normally be received when the user has posted a message to the online service, and the message is buffered by the control program 208 whilst it queries the user behaviour module. The query is performed at step 9.2, and comprises the control program passing a query message to the user behaviour module, the query message including the user IDs of the users who have posted the preceding messages to the chat room. With this information, at step 9.14 the user behaviour module looks up the user IDs of the previous posting users in the adversary table to determine the respective adversary percentages for the previously posting users. If it is determined here that a previously posting user is not listed in the adversary table, then this means that no other users of the online service have determined that the user has a relationship problem with the previously posting user, and hence no modification of the user's service need be performed. However, where a user ID is contained in the table, then the corresponding percentage is obtained therefrom. Next, at step 9.16 the determined percentages are used as input values to a time delay determination function. Figure 11 illustrates a suitable time delay determination function which may be used to relate the adversary percentage values to an actual time delay to be applied. More specifically, Figure 11 illustrates a first time delay determination curve 1102, which relates adversary percentage on the x axis to a time delay to be applied on the y axis. The curve 1102 extends from a threshold adversary percentage T below which no time delay should be applied up to a maximum time delay value max_delay_T1 which is the maximum time delay which should be applied when the adversary percentage value is 100%. The actual time delay represented by the value max_delay_T1 can be determined by calibration, but it is envisaged that a time period such as one day up to one week should be suitable. The time delay determination function curve 102 in this example does not apply a time delay at an adversary percentage value of less than a threshold T, to allow for low adversary percentage values not to incur any time delay. Of course, in other embodiments this may not be the case, and the time delay determination function may extend from the origin. Of course, the time delay determination function may be implemented as a mathematical function of the adversary percentage, or may instead be embodied in a look up table or the like. In operation, the time delay determination function is used to determine the actual time delay to be applied to the message at step 9.18. As mentioned above, individual time delays for each user ID in a user's adversary table can be calculated using the time delay determination function, and where it is apparent (for example in a threaded newsgroup) that the user is responding to a particular message from a specific other user whose user ID is in the replying user's adversary table then the time delay for that user ID can be used. However, where the on-line service is not threaded (such as is commonly the case in chat room applications), then it will not be apparent which of the other user's the user is replying to, and hence which time delay should be applied. In this case, the user behaviour module can calculate the individual time delays for each user who has previously posted a message (or, for scalability where many messages are posted, the previous n posting users (where n is for example between 5 and 20), or alternatively for those users who have posted in the previous f time period (where t is for example a day or a week)), and then calculate an overall time period from the individually calculated time delays, such overall time delay being, for example, a mean, median, or mode, or a maximum or minimum of the individual values. Moreover, even where the on-line service is threaded, a similar further calculation or evaluation may optionally be performed to find the final time delay. Howsoever the time delay is determined, at step 9.20 the determined time delay is communicated to the control program 208 from the user behaviour module. Once step 9.20 has been performed, the user behaviour module then re enters the wait state at step 9.4. Once the control program 208 has received the time delay from the user behaviour module, there are two mechanisms by which it may be applied. The first mechanism is that it might delay the posting of the message to the online service by the amount of time delay beginning from when the message is received at the web server computer 20. In this case, the time delay applied does not depend upon when the previous message from the previous sending user was posted to the online service. The alternative mechanism is to apply the time delay from the time and date at which the previous message from another user is posted to the online service. In this second mechanism, it may be that the previous message was posted so long ago that once the time delay is applied from that time and date the time delay will have already expired, and the user's message can then be posted to the online service immediately. This second mechanism prevents a user's message from being delayed unnecessarily when there is a long delay in any event between messages, but ensures that the time delay is applied when the user's message is a fast response to a previously posted message. In this respect, the inventors have noted that so called "warring" users of online services tend to respond very quickly to each others "flame" messages. An example of the operation of the described embodiments of the invention will now be undertaken with respect to Figures 1 , 13, 14, and 15. Here, Figure 1 illustrates a chat room application as generally known in the art, wherein the user Faye has with message 7 targeted the user Dave with an offensive message. In response the user Dave has targeted the user Faye with his own offensive message. It is this sort of disruptive behaviour that embodiments of the invention are intended to address. Referring now to Figure 13, let us assume that users of the online service have already identified that the users Faye and the users Dave exchange "flame" messages on the service, and have previously sent objections to the web server computer 20 concerning previous such messages. With this the case, the user behaviour module for the user Faye will contain an entry for the user Dave in its adversary table, and likewise the user behaviour module for the user Dave will contain an entry for the user Faye in its adversary table. Then, when the user Faye attempts to post message 7 to the online service, the control program 208 receives the message, but before passing it to the chat room program 210 queries the user behaviour module for the user Faye, passing the user ID's of the previously posting users thereto (as described above, the user IDs of the previous n posting users may be passed, or alternatively the user IDs of those users who posted in the previous t time period) . The user behaviour module then uses these user ID's to look up percentage values in the adversary table, and determines that the user ID "Dave" has an adversary percentage value thereagainst. Others of the user IDs may also have adversary percentage values thereagainst. The looked up adversary percentage values are then converted via the time delay determination function to respective time delays, and these time delays then combined with an appropriate logical or statistical function to produce an overall time delay, as described previously. In this case, as an example the system may find respective time delays for the previous 5 posting users (i.e. Eric, Dave, Clive, Ann and Bob), and then may take an average of these time delays to give the overall time delay to be applied. Alternatively, any of the other statistical or logical functions previously described may also be used to arrive at the overall time delay. The effect of application of the delay is shown in Figure 13. Here it will be seen that message 7 is not added to the chat room constituting the online service, and hence the conversational thread continues without the disruption of Faye's "flame" message. However, once the time delay has expired, Faye's message is then added to the chat room, but at this point, given the delay, the impact of the "flame" is reduced. Given this reduction it is thought that by delaying messaging in this manner then the sending of such disruptive messages in the first place may be prevented. Many variations may be made to the above described arrangement to provide other embodiments of the invention, as described next. In a further embodiment of the invention, the time delay determination function further incorporates a "time dependent" feature in that the delay which is applied to a user's message given a particular adversary percentage is dependent on the amount of time which has elapsed since the last objection to one of the user's messages was received. This is advantageously implemented by varying the maximum delay which may be applied as a function of time since the last objection message was received. It will be recalled that although objection messages are received by message analyser modules, whenever such an objection message is received the message analyser module outputs objection table data to the relevant user behaviour module. Therefore, by maintaining a timer at each user behaviour module, which keeps a track of the amount of time which has elapsed between the receipt of sets of objection table data from any message analyser module, then the maximum delay value which may be applied can be varied' as a function of this time. Figure 12 illustrates various functions which vary the max_delay value as a function of this time, such as curves 1202, 1204, 12076, 1208, and 1210. As shown in Figure 12, as the time which has lapsed since the receipt of set of an objection table data is increased, the maximum delay which may be applied to the user's message is generally decreased. The decreased max delay value may then be applied to the time delay determination function as shown in Figure 11, where a reduced max delay value max_delay_T2 is used to give a time dependent determination function characterised by curve 1104. By using curve 1104 to look up time delay values as a function of adversary percentage, it will be seen that for each adversary percentage value, the time delay function to be applied is reduced, when compared to the curve 1102 described as being used previously. Moreover, various changes can be made to the time determination functions themselves to provide further embodiments. In the embodiments described above the time determination functions are depicted as curves of increasing gradient, but any function relating adversary percentage to time delay may be used, although preferably the function is substantially monotonic. Likewise, almost any function can be used to relate time since the last set of objection table data is received to the maximum delay value, as shown in Figure 12. In further embodiments of the invention, instead of an actual time delay value being applied, the system could instead wait until a certain number of other messages have been posted to the online service, before then posting the delayed message. Such a mechanism would be implemented in an identical manner to that described previously, although instead of the delay axis of Figure 11 relating to amount of time by which a message should be delayed, it would instead relate to the number of messages by which the message should be delayed. Such a modification would ensure that a branching in the thread of messages occurs and could be used as a stronger form of sanction than a mere time delay. In other, less refined, embodiments of the invention, instead of using the delay determination function of Figure 1 1 , the delay to be applied (either as a time based delay or a number of message based delay) could be predefined as an absolute value. However, this is not preferable, as many benefits of the additional refinements of using the time delay function are lost. It will have the advantage of simple implementation, however. As further modifications, when a message which has been delayed is finally posted to the online service, the control program 208 may control the chat room program 210 to indicate in its output that the message has been delayed. This indicates to every user of the online service that the user who sent the message has sent the message has had his use of the service modified by having his message delayed. In a yet further embodiment, the delay which is to be applied to a message might be made known to a user in advance such that they are then dissuaded from even submitting a "flame" to the system. This could be achieved by modifying the output of the online service to include for each user an indication in their view of the messages as to what delay a message sent in reply to an already posted message will incur. Such a modification is shown in Figure 15, wherein a first display portion 2 of the application 1 comprises an extra information column 9 which specifies next to each displayed message the, amount of time in hours that a message sent in response to a displayed message will be delayed prior to being posted. In this example, it will be seen that a message sent in response to message 5 will be delayed by 24 hours, whereas a message sent in response to messages 6 or 12 will be delayed by 15 hours. It will be appreciated that the units of delay may be any unit of time i.e. minutes, hours, days or even weeks, or instead of a unit of time may be a number of further messages, as previously discussed. In order to implement such a display mechanism, the chat room program 210 would need to compile a separate display page for each registered user presently using the online service. When a display page is being compiled for a particular user, the chat room program would then query the user behaviour module for that particular user, and ask the user behaviour module to specify the delays that would be incurred by that user responding to each posted message displayed in the display. The values returned from the user behaviour module can then be incorporated in the delay column 9 in the display prepared for that particular user. Further variations may also be made to the above described arrangements to provided further embodiments, as described below. For example, in a further embodiment the Message Analyer Modules can be deleted after relatively short periods of time (-days), and so no serious scalability issues are anticipated. In other embodiments the Individual objections may be visible to different degrees, and to different members of the community. In these embodiments the free-text part received in the text comment field 78 of an objections messages is made publicly- visible. This might reduce 'copycat' objections. Alternatively, this is made visible only after a message's active life has expired (i.e. when no further objections to the post can be created). In further embodiments there may be some constraints limiting who can actually instigate an 'objection'. For example, the previous poster to that thread is unable to object, or perhaps objections cannot be made beyond a certain time period (the concept of an 'active lifetime' for posts), or perhaps only the instigator of a thread can make an objection, or previous posters to that thread, or if they had already objected to that message they may not be able to do so again. In some discussion groups, identity may only be required by those actively posting to the group (i.e. you may need to log-on before posting). In such systems, potential objectors would also need to log-on before their objections would be counted (or at least, they might be weighted much more heavily if identified, than if they were to remain anonymous (where multiple voting would be much harder to detect).

Additionally, in other embodiments the time delay determination algorithm might require a quorum of disapproving raters to suggest 'separation' of two individuals before any time penalty is actually enforced, i.e. just because one person finds two people's posts inflammatory and unhelpful does not necessarily impose a sanction on them. Finally, in extra embodiments weightings may be given to individual objections according to the general reputation of the person objecting. 'Reputations' may be determined by other means within the system, or may derive directly from their own time penalty metrics (the smaller their penalties, the greater the weighting given to their objections). However, because we expect this overall system to dramatically reduce the frequency of disruptive behaviour altogether, weighting in this way may be less necessary than imagined. In the examples above, the sanction applied to modify a user's use of the online service is that a time delay is applied to the messages before being posted to the chat room. In these systems a user either has no explicit knowledge of the time sanction to which their posting may be subjected, or is explicitly made aware of the sanction to which their response will be submitted (for example in the system of Figure 15). As an alternative modification, however, antagonists may be forbidden from submitting their response until the time penalty has been 'served'. This has two particular effects: i) it will avoid 'out of date' posts being added to the discussion; and ii) it will impose a 'period of reflection' on people during which they might give a more considered response, or after which they're response can take consideration of others' subsequent responses. Such a modification could be implemented by the control program simply refusing to accept messages posted from a user who has a time delay penalty. In the above architecture of the above described embodiments, if a message is received the user behaviour module for the sending user is queried, and if a time delay is returned then the received message is discarded, and a response message sent to the sending user informing him that his use of the service is forbidden. In an alternative embodiment to the above, even if forbidden from responding directly, instead of being completely prevented from posting the message the antagonist may be permitted to create a new sub-thread in which his agenda is pursued (i.e. the 'thread context' will hugely influence the sanction). This would then be displayed as a completely separate and new thread in the display portion 2. Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise", "comprising" and the like are to be construed in an inclusive as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to".

Claims

1. A method of regulating the use of an on-line service, comprising the steps of: a) receiving input about a first user's use of the on-line service with respect to at least a second user from one or more other users; and b) modifying the first user's ability to use the on-line service in dependence upon the received input.

2. A method according to claim 1 , wherein the modifying is selectively applied dependent upon use of the on-line service by the second user.

3. A method according to claim 2, wherein the modifying is selectively applied after use of the on-line service by the second user.

4. A method according to claims 2 or 3, wherein the online service is a message based service wherein users post messages to the service which may then be viewed by other users, and wherein the first user's ability to use the service is modified after the second user has posted a message to the service.

5. A method according to any of the preceding claims, wherein the modifying step further comprises delaying the first user's use of the on-line service.

6. A method according to claim 5, wherein the use is delayed by a predefined time period.

7. A method according to claim 5, wherein the use is delayed by a time period calculated as a function of the received input.

8. A method according to claim 7, wherein the function relates the time period to the number of input messages received relating the first user and the second user.

9. A method according to claim 5 when dependent upon claim 4, wherein the use is delayed until a number of further messages have been posted to the on-line service.

10. A method according to claim 9, wherein the number of further messages is calculated as a function of the received input.

11. A method according to claim 10, wherein the function relates the number of further message to the number of input messages received relating the first user and the second user.

12. A method according to claim 9, wherein the number of further messages is predefined.

13. A method according to any of the preceding claims, wherein the modifying is dependent on the time since the input was received, such that the first user's use is modified less with respect to time since the input receipt.

14. A computer program or suite of computer programs arranged such that when executed by a computer it they cause(s) the computer to perform the method of any of the preceding claims.

15. A computer readable storage medium storing a computer program according to claim 14.

16. A system for regulating the use of an on-line service, comprising: a) means for receiving input about a first user's use of the on-line service with respect to at least a second user from one or more other users; and b) service control means arranged in use to modify the first user's ability to use the on-line service in dependence upon the received input.

17. A system according to claim 16, wherein the modifying is selectively applied dependent upon use of the on-line service by the second user.

18. A system according to claim 17, wherein the modifying is selectively applied after use of the on-line service by the second user

19. A system according to claims 17 or 18, wherein the online service is a message based service wherein users post messages to the service which may then be viewed by other users, and wherein the first user's ability to use the service is modified after the second user has posted a message to the service.

20. A system according to any of claims 16 to 20, wherein the modifying step further comprises delaying the first user's use of the on-line service.

21. A system according to claim 20, wherein the use is delayed by a predefined time period.

22. A system according to claim 20, wherein the use is delayed by a time period calculated as a function of the received input.

23. A system according to claim 22, wherein the function relates the time period to the number of input messages received relating the first user and the second user.

24. A system according to claim 20 when dependent upon claim 19, wherein the use is delayed until a number of further messages have been posted to the on-line service.

25. A system according to claim 24, wherein the number of further messages is calculated as a function of the received input.

26. A system according to claim 25, wherein the function relates the number of further message to the number of input messages received relating the first user and the second user.

27. A system according to claim 24, wherein the number of further messages is predefined.

28. A system according to any of the preceding claims, wherein the modifying is dependent on the time since the input was received, such that the first user's use is modified less with respect to time since the input receipt.

29. A method of regulating the use of an on-line service, comprising the steps of: a) receiving input about a first user's use of the on-line service from other users; and b) delaying the first user's use of the on-line service in dependence on the received input.

30. A system for regulating the use of an on-line service, comprising: a) means for receiving input about a first user's use of the on-line service from one or more other users; and b) service control means arranged in use to delay the first user's use of the online service in dependence upon the received input.