EP1334449A2 - Data processing system - Google Patents

Abstract

An information dissemination system operating primarily via the wireless Internet and mobile phones. The system comprises 2 sets of subject and message records (26, 27) (for RTR, Real Time Reporting) and (28, 29) (for CR, Continuous Reporting), a set of user records (23), means for a user to add data to the message records, and means for a user to read data from the message records. Rating means (31) determine, for each user submitting messages, a rating dependent on the quality (subjective, ie feedback from other users, and/or objective) of those messages. A user can register an interest in a subject, and then receive alert signals relating to new messages relating to that subject, and then communicate directly with other users. The system also determines user profiles and matches users with similar profiles.

Description

Data Processing System

Field of the Invention

The present invention relates to data processing systems, and more specifically to information dissemination or exchange systems intended to allow a plurality of users to disseminate information among themselves.

The present invention finds particular application to the wireless Internet, although it is not limited thereto. The presentation and transmission of data over the wireless Internet is governed by a number of standards throughout the world. Currently, the wireless Internet in Europe uses WAP (Wireless Application Protocol), although it is not limited thereto. WAP is a specification for a set of communication protocols that standardize the way that wireless devices, such as cellular telephones and radio transceivers, can be used for Internet access, including e-mail, the World Wide Web, newsgroups, and Internet Relay Chat (IRC). The wireless Internet is developing rapidly, and will differ from the present fixed line Internet systems in various ways. These are based on various technical advances, such as easier connection and higher bandwidth. For example, it will be possible for mobile phones, computers, and personal digital assistants (PDAs) to effortlessly interconnect with each other and with phones and computers using a short-range wireless connection such as Bluetooth. Similarly, computer and phone users will be able to be constantly connected to the Internet as they travel and, as they roam, to have the same set of capabilities no matter where they travel. New services, such as alternative billing methods, asymmetric bandwidth, and video conferencing, are likely to become widespread. Similarly, location determination technology, such as Global Positioning System (GPS), is likely to be incorporated in mobile phone handset designs.

Background of the Invention

The present system is concerned primarily with providing "non digital" information, anywhere and at any time, to distinct groups of wireless Internet users

(by "non digital" we mean data that is not currently collected by electronic means). The present system provides a means whereby consumers can access an information exchange compiled by the users themselves. This exchange will encourage users to contribute, or report, valuable information which others can view and/or buy to enhance their daily lives. The information may relate to any subject of interest to a number of users. Typical examples are venues and items such as a bar/restaurant or a concert/gig. However, the subject reported on could conceivably be any subject capable of supporting an opinion over time (e.g. fly fishing in Colorado) or a subject of interest to consumers at a point in time (e.g. traffic reports in London).

There are various on-line services available which permit users to submit comments or reviews relating to items presented by those services. For example, Amazon allows users to submit comments (reviews) on books which are advertised by Amazon. Currypages.com is a website that provides reviews and information on Indian restaurants in the UK; users have the ability to enter reviews on restaurants via their WAP mobile phone to the service, and other users then have the option to read this review if they desire. And Quios is a consumer/business mobile services company that through its PlanetQuios service allows users to register an interest in a particular subject (eg American football) and receive messages from a user who submits relevant data (eg latest match result) which is sent to multiple interested users via SMS/email. In such systems, there is effectively no rating of the information entered or of the users of the system rated in terms of quality. Essentially, it is left to individual users to assess the quality of comments from others.

It is of course possible for the system provider to moderate the comments or reviews, ie to edit, filter, or censor them. In addition, it is possible to provide a feedback comments system, whereby a user can submit comments on the comments of another user. Such a system becomes, in effect, a kind of chat room system, where chains or strings of comments on comments can exist.

The basic purpose of the present system is to provide, in an information service system in which information is submitted by users, an automated quality assessment system. Summary of the Invention

Accordingly the invention provides an information dissemination system comprising at least one set of message records, a set of user records, means for a user to add data to a set of message records, and means for a user to read data from a set of message records, characterized by rating means for determining, for each user submitting messages, a rating dependent on the quality of those messages. The quality of a message may be determined from objective characteristics of the message; by "objective characteristics", we mean characteristics such as a time or location referred to in the message relative to the time or location of the message itself, inconsistency between different parts of the message, and so on. The quality of the message may instead be determined from subjective characteristics, ie by rating comments from other users who read the message. Both types of quality assessment may of course be used.

The system then links the ratings of the users with the messages those users submit. The rating of a message may be attached explicitly to the message, ie is presented to a user who reads the message. In some situations, however, the rating of a message may be applied only implicitly, for example where several messages are combined into a single compound message; in that situation, the individual messages being combined may be weighted according to their ratings; similarly, messages may be filtered so that those with high ratings are presented to other users while those with low ratings are discarded.

There is preferably a plurality of sets of message records, one for each of a plurality of different subjects. Preferably the system can record messages from users which can be transmitted substantially direct to other users as data, and also compiles summary information from a plurality of messages received from users for transmission to other users as data. The rating means preferably comprise user rating means for recording, for each user, rating values for other users.

The system preferably operates in two modes, Continuous Rating (CR) mode and Real Time Reporting (RTR) mode. Preferably, the system includes means for a user to register an interest in a set of message records, i.e. a subject, the system thereupon sending to that user an alert signal relating to messages relating to that subject. The system preferably also provides means for then enabling the user registering an interest in the subject and the user providing a message relating to that subject to communicate with each other on a one-to-one basis. Preferably also the system includes means for recording, for each user, a user profile indicating the user's assessment of other users as information providers, and means for automatically matching a user profile with other user profiles and, on finding a reasonable match, giving the user the option of modifying their profile in the light of the other user profiles. The user assessments may conveniently be related to the ratings mentioned above.

Considering the preferred features of the system generally, the system comprises a reporting and recommendation system centred around an information exchange where the users of the system and all the information entering the exchange is rated in terms of quality. The system ensures that the correct user is identified; a user can navigate the site; a user's cumulative interaction with the system is used to assess the user's overall ranking on the exchange; all input data is reviewed in terms of quality; and all data is compared, manipulated, and combined with other data to produce and communicate information to users of the exchange. Information is entered via a menu driven / predefined text template interface. The users are wirelessly linked to a centralised server by mobile terminals (telephone devices), and the system includes the software required to navigate, verify, manipulate, and communicate information and for the telephone devices to act as a component of the system. The system also includes an alert system, a natural language generator, News Mail, and collaborative filtering; these features interpret, analyse, and distribute the information contained in the exchange.

The system forms a self-policing exchange whereby all users are tracked and rated in terms of quality. All the information entered into the exchange is automatically screened and then ranked in terms of the quality of the information itself and the reliability of the user who submitted the information. Thus the system provides information (preferably including real time and local information) that is compiled by the system users themselves, with the information being automatically screened and rated by the computer system and the users having the ability to customise their experience of the system.

The present system is an information provision service, information service system, or information exchange. In the preferred form of the system, all users of the exchange are rated in terms of quality and their track record. This rating is based on the views of the other users of the system, so the system provides in effect a complete community self-policing mechanism. All information entered into the exchange is screened in terms of quality and rated in terms of the relative ranking of the person who submitted it in the exchange. This is carried out by a suitable set of algorithms. External inputs such as location-based information are also included as additional means of assessing the validity of submitted information.

Users can personalise their experience of the exchange and decide what other individuals they interact with and what information they are presented with. They have the ability to customise their experience of the exchange through a "broadcast and reception information filter" module.

The system has two modes, Continuous Rating for non time sensitive information and Real Time Reporting for time sensitive information. The system includes an alert mechanism, used particularly for the latter mode, whereby users who request certain information are alerted via SMS/email that the relevant information has been entered on the exchange.

Detailed description of Preferred Embodiments

A system embodying the invention will now be described, by way of example, with reference to the drawings, in which: (Brief Description of the Drawings)

Fig. 1 is a block diagram showing how a user communicates with the system;

Fig. 2 is a block diagram of the system;

Fig. 3 is a general flow diagram of the operation of the system;

Figs. 4-7 are more detailed flow diagrams of the four main options of the Fig. 3 flow diagram; and Fig. 8 is a more detailed block diagram of the main functional modules of the system. It will of course be understood that the present description is considerably simplified, and is intended to illustrate the essential features of the present system while omitting many details which are within the design ability of competent software design engineers to implement.

Before describing the structural and operational aspects of the system in detail, it is convenient to discuss some of the concepts and principles used in the system.

Trust ratio

Each user of the system has a Trust Ratio (trust rating), which is a factor of the frequency of use, quality of the information and other reporters' feedback on the user; the Trust Ratio ranges from 0 (totally untrustworthy) to 1 or 100% (totally trustworthy). The system's User Rating Engine determines the Trust Ratio, which is a software module that performs the calculation of the Trust Ratio. The Trust Ratio of a user at a point in time reflects the value of that user's interactions with the system to date. While the concept behind Trust Ratio is the same for both modes, the actual calculations of Trust Ratios in RTR and CR differ, due to the varying importance of inputs such as timely user feedback etc.

CR and RTR modes

In its preferred form, the present system has two distinct but related modes: Continuous Rating (CR) and Real Time Reporting (RTR). Both modes are mobile based (anytime, anywhere), gather information from a large number of users, and use a common generic screen-based interface and system mechanics to enter non-digital information into a digital format to be manipulated and stored on a central database server. However, the Trust Ratio is calculated differently for each mode, due to the emphasis on different performance traits of reporters in RTR and CR.

In simple terms, the Continuous Rating mode provides users with a review of a subject aggregated over time (e.g. a certain Greek restaurant has excellent service, good food and is reasonably priced), while the Real Time Reporting mode provides up-to-date information or news (e.g. traffic is heavy on the M25). Time is the distinguishing factor; for Continuous Rating, the information is useful over an extended period, while up-to-date data is essential for Real Time Reporting, the reports of which are valid for short time periods. Continuous Ratings are arrived at through the aggregation and manipulation of reported information over time (the survey never ends). This requires a verification system to ensure data integrity over an extended period.

Real Time Reports are created from distinct pieces of timely information that are captured and screened by the Reporter system. The RTR mode is applicable to a wide range of subjects, e.g. traffic reports, clamping hotspots, etc. This mode is more comparable to a news generation service than the review based Continuous Rating. In essence it creates an efficient information exchange whereby Reporters are rewarded for placing useful information onto the system that is then viewed/purchased by others. The two modes are of course interrelated; for example, a user could view a week-old CR on a restaurant and access a 15-minute-old RTR on how busy the restaurant currently is.

Alert system It is desirable for the RTR mode to operate in conjunction with an alert system where a user requests information and is informed of its arrival through an alert such as SMS/email (though this could conceivably be any form of electronic alert). The ability for users to establish alerts is important for the effective operation of the RTR system. For example, a user may set an alert to be notified when an up-to-date traffic report is submitted. If the user receives an alert 10 minutes later, they can then enter the present system and read the traffic report.

It is also desirable for the RTR mode to enable a user who requires a report to establish a real time direct link with another user who can supply this information. This one-to-one link may be conducted via electronic messaging, voice connection, or other electronic means that allows the information to be exchanged in real time. The user supplying the information will have -registered in advance their ability to provide a report should another user request it. For example, on a Monday night a Reporter in a bar in Paris may register their ability to provide information relating to that bar throughout the night. At 8.00pm another user requests that a direct link be established between themselves and the Reporter to obtain information relating to that bar. The link is established, the information is exchanged, the user views/pays for the information, and the Reporter is rewarded for submitting the data.

Reporter types

In the present system, there are different user classifications depending on their level of participation in the system: Named Reporters, On-the-Spot Reporters, Trusted Reporters, and Suggested Reporters, as follows:

A Named Reporter is a user who may read an existing report and submit a confirmation of it or may rate a subject in terms of overall scoring and submit a personal report. This individual report is therefore available for reading, together with the summary rating for the subject. The individual report is displayed, possibly after the summary rating, along with the Reporter's user-ID and Trust Ratio. Other users can read an individual report and provide feedback on its usefulness.

An On-the-Spot Reporter is a Reporter who has pre-registered their ability to provide up-to-date information on a subject or venue should another user request it. In practical terms, an On-the-Spot Reporter is a typical user who is distinguished by the fact that they can provide real time data on a subject. A Trusted Reporter is a Named Reporter selected by another user to be included on that other user's Trusted List (personal list of Trusted Reporters) because that user has a preference to read reports submitted by this group of

Reporters. The Trusted List facility allows users to establish an easily accessible group of preferred Reporters to obtain reports on venues/items from.

A Suggested Reporter is a Reporter that the system suggests to a user as what it believes to be a "like minded individual". The User Profiling module in the system attempts to analyse users' interest in subjects/items over time and propose a Suggested Reporter to a user as somebody they may want to receive information from. The concept is similar to a Trusted Reporter except that users select Trusted Reporters themselves whereas Suggested Reporters are system generated.

The different classification of Reporters is more for ease of understanding as opposed to substance - for instance, Trust Ratios and rewards are calculated in the same way for all Reporter types. A Reporter may belong to various classifications - an individual Reporter could be both a Named and an On-the-Spot Reporter, for example.

Report types

In the present system, there are two different report classifications depending on the volume and timeliness of reports submitted - consensus reports and individual reports. Consensus reports represent the aggregate view of a group of Reporters, whereas individual reports are the opinions of a single Reporter. This concept is applied to both of the RTR and CR modes.

For example, the review of a restaurant in CR will comprise a summary consensus report on the restaurant in terms of the fixed attributes to be evaluated - "service, food, decor, and cost" - which will be built up over time from the aggregate views of Reporters who submit reports on the venue. In addition there are the individual written reports, which Named Reporters submit, to comment on other attributes of the venue that they may want to comment on - e.g. "I particularly liked the free after-dinner drink that is served".

Aggregated consensus and individual reports also exist in RTR but with a slight difference to CR. The distinction in RTR revolves around the relatively higher importance of time in the RTR mode. The consensus report facilitates the publication of a single report that summarises many Reporters' submissions in a single time period (e.g. 100 people report that the M25 is very busy at various times between 5.00pm and 5.10pm, therefore a consensus report is issued which is not attributable to a single Reporter - "5.00 - 5.10pm traffic on the M25 is extremely busy"). If only one Reporter submitted a report on the M25 at this time, then an individual report would be published attributable to a single Reporter.

Request/alert types In the present system, there are three different request/alert types depending on the type of information requested - time related requests, event related requests, and requests for one-to-one interaction.

Time Related Requests (RTR only). These operate only in RTR mode where time is a significant distinguishing factor. A user can opt to register a Time Related or "Tell me at" Request to receive a piece of information at a specified time in the future. For example, at 2.30pm a user views the current traffic reports for the M25 and submits a request for a traffic report at 5.00pm - "Tell me at 5.00pm how heavy the traffic is on the M25". Event Related Requests (CR + RTR). These (which can also be described as "Tell me when" requests) apply to both RTR and CR modes. A user registers a request to receive notification when a certain event takes place/situation arises. For example, in RTR a user may request to be notified when the traffic on the M25 has dropped to a low level or a CR user may request to be notified when a new report on a certain restaurant is submitted by another user. One-to-One Interaction Requests (RTR only). As with Time Related Requests, these (which can also be described as "Tell me now" requests) operate only in RTR mode. A user who requires up-to-date information can establish a real time direct link with another user who can supply this information. The user supplying the information (i.e. an on-the-spot reporter) will have registered in advance their ability to provide this specific piece of information should another user request it.

When the system responds to a request, it sends an alert message. Alerts will normally be short signals (e.g. up to 160 characters), though in principle they could be complete messages. The system can include links (hyperlinks) in alerts. Trust List and User Profiling

The Trust List facility and Intelligent User Profiling are valuable features of the system. The Trust List facility allows a user to establish a list of Trusted Reporters because the user has a preference for reading reports submitted by this specific group of Reporters. As a user views reports submitted by other users, they can decide to "bookmark" a preferred Reporter on their Trusted List for future reference. The user is then notified whenever one of their preferred Reporters submits a report.

The concept behind the Intelligent User Profiling system is similar but has one fundamental difference - the users themselves build the Trusted List whereas the system automatically suggests, to the user, those Reporters or venues/items which it believes to be of a similar mind and range of preferences. This is done by a User Profiling module, which attempts to analyse users' interest in subjects/items through a technique called collaborative filtering. This software module has the ability to analyse and compare user profiles/activity and suggest like-minded individuals to users or subject areas that may be of interest, as "people like them also like this subject", etc. This is achieved through the use of suitable algorithms and profiling engines.

In simple terms, collaborative filtering is really about trying to make the system smart enough so that it effectively knows a user as an individual, thereby empowering the users to navigate information more effectively. Collaborative filtering attempts to guide a Reporter's choices of what to read, what to look at, and what to watch (the filtering part); and doing that guidance based on information gathered from some other users and themselves (the collaborative part). For example, the system may track what restaurants a Reporter rates highly, find other users who also rated these particular restaurants highly, determine what other restaurants they also rate highly, and suggest to the Reporter that he may wish to visit these other restaurants as people like him rated them highly. Similarly, collaborative filtering is extremely beneficial for "negative" rating situations. For example, if a user does not like sedate type bars and relatively serious movies, the system will filter this information and, through analysis of other users' preferences, may suggest that he/she should visit the local comedy club as people like him/her appear to enjoy stand up comedy. Collaborative filtering is a means of analysing very subjective information such as personal taste and lifestyle and producing relevant and focused suggestions. This is quite a powerful feature as, over time, the system will suggest to or alert users that there is information in the database which they are not aware of but which could be of interest and benefit to them. Reporters may be notified of users who are similar to them, venues that they are not familiar with but they possibly may enjoy, and subject areas that are of interest to them. In its most sophisticated form, the Reporter system with collaborative filtering could form the foundation of a highly personalized up-to-date lifestyle recommendation system.

System hardware

Fig. 1 illustrates how a user communicates with the present system 15. A user may communicate with the system via a wireless device or fixed line Internet browser or by transferring from a third party website. The user's wireless device 10, for example a mobile phone, is coupled via a wireless link with a mobile system operator base station 11, which is coupled to the base station's operations centre 12. When the user wants to communicate with the present system 15, they connect to the system. The connection can be routed via the mobile system operator's gateway 13 and the Internet 14 to the server 16 of the present system 15. Alternatively, the caller can connect to the present system direct, gaining access to the server 16 via a gateway 17 forming an interface between the caller and the server 16. Once the connection has been established, the micro browser in the mobile phone reads and displays WML pages, for example (WAP version of HTML pages) on the mobile phone screen, where the device has this capability. Otherwise information is displayed in a stylised format (via SMS for example) determined from a set of predefined text templates held on the server. These pages will show text and/or links to other pages or sites. Once the user has visited the present site, this appears on the user's mobile telephone as a menu driven report and reading system comprising a set of WML pages or SMS messages based on predefined text templates. A fixed line Internet user may also enter the system directly via a browser connected to the World Wide Web 19. Alternatively, the user may be transferred to the system via dynamic links on a third party site 18.

Fig. 2 shows the main blocks of the present system. Users are coupled to a control unit 20, which has two databases coupled to it: a user database 21 and a message database 22. The control unit 20 includes a message rating engine 30, a user rating engine 31, an intelligent user profiler 32, an alert/chat manager 33, and a rewards engine 34. The user database 21 comprises a set of user records 23. The message database 22 is divided into two sections, a Real Time Reporting section 24 and a Continuous Reporting section 25. The RTR section comprises a plurality of sets 26, 27, etc of RTR subjects and messages and the CR section comprises a plurality of sets 28, 29, etc of CR subjects and messages; there is a different set of messages for each subject which the system can deal with.

General operation

Fig. 3 is an overall flow diagram of the system. The Start block 35 is effectively the home page of the system, and offers a choice of four options. The first option is block 36, Register (as a new user). Option 37 is an Add Information option; this option is selected if the user wants to enter information into the system. Option 38 is a Read Information option; this is selected if the user wants to read information already in the system. The fourth and final option is option 39, Amend Details (of user); this is used if the user wants to amend the details recorded for them. All four options terminate in block 40, End/Return, which allows the user to end the session or to return to the home page to enter another option immediately. (Block 41 will of course be skipped once the user has registered or been identified.)

Option 36, Register, can be accessed directly from the home page 35. The remaining three options are for registered users, and are accessed via a user verification block 41, which implements a suitable log-in procedure and then allows the user to enter the site. Option 36, Register, is effectively an administrative option which will be used only once by a user, or not at all if they are pre-registered by a third party; Option 39, Amend Details, is effectively also an administrative option which will usually be used relatively infrequently. Options 37 and 38, Add Information and Read Information/Set Alert, are the two main options, which will normally be used.

Register option 36

Fig. 4 shows this option in more detail. Becoming a user of the system is a simple procedure whereby a user chooses a unique identifier (userlD) (block 45) and password (block 47). This information, along with a system generated unique contact reference, is recorded by the system as a record 23 in the client (user) database 21. For example, a user may choose "ReporterlOO" as their userlD; therefore the system will record ReporterlOO@system.com as their unique contact reference. Block 45 is followed by block 46, which checks that the username is available (i.e. is not already taken by another user). In practice, the user will usually also be requested to supply further information to form a user profile from answers to lifestyle questions (subject of course to privacy considerations). Once a user has been registered, all messages submitted by them and all information requested by them can be tagged with their identity, so that a full audit trail exists for them.

Add Information option 37 Fig. 5 shows this option in more detail. The option initially passes through the user identification block 41, and proceeds to a subject selection block 51, in which the user selects a subject of interest. Typically, the system presents the user with a series of choices, e.g. subject name (e.g. Bistro Cafe or M25 traffic), attribute (e.g. cafes and restaurants or traffic), or location, typically in alphabetical order. The user works down through the series of options until they reach the desired subject. A location determination technology, such as GPS, will assist in this process. Then, in block 52 the user is asked whether they want to enter a standard report. If they do, they go to block 53, where the standard report is entered. Next, in block 54, they are asked if they want to enter a more detailed personal or written report; if they do, they go to block 55, where the personal report is entered. Next, in block 56, the user is asked whether they want to register their availability to respond to "Tell me now" alerts and provide one-to-one interaction reports. If they do, they go to block 57, where the Reporter registers their interest, how long they will be available for, and how many requests they are prepared to accept, as an On-the-spot Reporter for this subject. They then go to block 58, where they are asked whether they want to read any existing information on the subject. The sequence ends at block 40, which returns them to the main sequence of Fig. 3.

It will be realized that block 59 effectively reproduces the Read Information sequence 38, possibly in somewhat simplified form. Block 40 can offer the option of returning back to block 51 direct, in case the user wants to enter information on another subject without having to go right back to the start block 35. Other variations and elaborations are obviously possible.

Read Information/Set Alert option 38

Fig. 6 shows this option in more detail. The option begins from the user identification block 41, and proceeds to a subject selection block 60, which is effectively identical to block 51. Similarly, a location determination technology, such as GPS, will assist in this process. The user is asked in block 61 whether they want to establish a request for up-to-date information or to view existing information on the subject. If they opt to establish a request, they go to block 62, which presents a range or list of alerts that the user may choose from (e.g. time/event related or one-to-one interaction request). If the user requests a time/event alert (Tell me when/Tell me at), then the request is registered and the user will be notified via an electronic alert when the information requested is submitted by another Reporter. The user will then re- enter the system and read the information/message. If the user requests a one-to-one interaction (Tell me now), then the system attempts to connect the user to an On-the- spot Reporter and the information exchange takes place. After completing block 61, the user proceeds to block 74, where they are asked whether they wish to view another report. This returns the user to block 61 or passes them on to the end block, block 40. As mentioned, the user can either establish a request/alert or read an existing report. If they opt to read a report, the system proceeds to block 63, where they are presented with a review of the summary report/rating of the selected subject and the option (via block 64) to view comments from a Named Reporter. If they select that option, they are presented with a list of reporter comments from which the user selects a particular Named Reporter's comment (block 65). The user then has the option to enter a rating for the Named Reporter (block 66). If they choose to do so, block 67 allows them to rate the Named Reporter on the basis of predefined criteria. The user is then presented with the option to view a Named Reporter's profile (block 68) and the ability to drill down into the Named Reporter's history on the system (block 69). The user also has the option (block 70) to add the Named Reporter to their Trusted Reporter list (block 71). The user also has the ability to initiate a "Chat" session with the Named

Reporter from whom they have read a report (block 73). If the user decides to use this option, electronic messages are exchanged between the user and the Named Reporter (block 73) until the chat is deliberately terminated or reaches its natural conclusion. All chats are anonymous, as only the users' system identifications (i.e. usernames) are visible to each user. The system is designed to automatically link a message recipient's userlD to their private phone number/email address.

Finally, the user is then asked whether they want to view further reports on the chosen subject or view other Named Reporter reports (block 74). This returns the user to block 61 or passes them on to the end block, block 40.

Alter Details option 39

Fig. 7 shows this option in more detail. The option begins from the user identification block 41, and proceeds to block 75, View Personal Reports?. A user can review details of their own reports made in the past via block 76; reports (including user feedback) are stored, and each report has a unique identifier which enables it to be retrieved. The system then proceeds to block 77, Review Personal Profile/Favourites? A Yes choice leads to block 78, in which the user's personal profile/Favourites is listed. User profile data covers areas such as personal interests, hobbies, etc; the Favourites section is a tool to "bookmark" venues that a user may review on a regular basis. (Bookmarks are a useful time saving feature, allowing rapid access to bookmarked venues.) Block 79 allows the user to edit their current profile and bookmarked list of Favourite venues. This can be done at any time.

The system then proceeds to block 80, Alter Trusted Reporter list? Each user can maintain a list of Trusted Reporters, which is stored in the user's database record 23. A Yes response leads to block 81, in which the Trusted Reporters are listed. Block 82, View Trusted Reporter profile/reports?, allows the user to select block 83, which displays the Trusted Reporter profile and reports submitted by them. This is followed by block 84, Delete Reporter From Trusted List, which allows the user to select block 85, in which they can delete a Trusted Reporter from their list. It will be realized that while each user has their own listing for their Trusted

Reporters, there is no listing for Named Reporters. This is because any reporter who submits a personal or detailed report (as distinct from a simple set of ratings) is automatically a Named Reporter. Each such report identifies the reporter who submitted it. There is also a facility for users to review electronic "chat" messages sent to and received from other users. Block 86, Review Chat Summary, allows the user to select block 87, which presents the user with a list of current "live" chats and a record of recent chat activity. The user also has the ability to terminate a now dormant chat (e.g. series of electronic messages over just one night) or prematurely terminate a chat that is no longer enjoyable. When a chat is prematurely terminated, all contact between the two specific users ceases but each is free to continue with other chats or establish new ones with other Reporters. The system then proceeds to block 88, which enables the user to change their location, e.g. from Dublin to Paris. This is done by block 89, which offers the list of available locations and allows the user to select a new location. This effectively allows users to set the system to provide them with information relevant to their current location. This can be done at any time.

The Alter Details option ends with block 40, Return, like the other options.

System modules The above descriptions of the main system options have referred to reports and ratings of various kinds. The Message Rating Engine 30 and the User Rating Engine 31 maintain these reports and ratings, which operate in conjunction with the User Profiler 32, the Alert/Chat Manager 33, and the Rewards Engine 34 (Fig.2).

Fig. 8 shows the main functional modules of the system. The system is conveniently distributed over three groups of hardware components: the user's terminal 10, the central server 16, and third party systems 12. The user terminal and the central server are both regarded as internal parts of the system. The heavy lines show major internal data flows, the light lines show standard internal data flows, and the broken lines show external data flows.

User terminal/WAP browser

The user's terminal (for example a mobile wireless device 10) is an Internet enabled device with a browser such as a WAP micro browser (although it is not limited thereto), which displays WAP pages and allows the system to be navigated by the user. The central server has resident on it various software modules which perform most of the implementation of the present system, together with a central relational database which stores all relevant user and report/message data; this database, which is effectively a combination of the databases 21 and 22 of Fig. 2, is interrogated and updated by the software modules. There are also modules which manage links, such as electronic messaging or reward/billing, to external third party systems; these modules may be resident in either the central server or the third party system, as convenient.

Considering first the activities on the browser or device, the user accesses the present site via this browser or device in accordance with its capabilities (e.g. WAP micro browser or simple text messaging system). The user is served pages or SMS messages from the server as directed by the System Navigation module 101. The System Navigation module can be configured to understand a number of protocols serving and receiving information in a format appropriate to the access browser or device. This could be menu or template driven accessed by any convenient means, such as keypad or voice.

The WAP browser drives a Log-in/User-identification Welcome-Screen module 102, by which the user logs onto the system using a unique identifier and password. This may be manual, or may be an automatic procedure whereby a user's phone number or ID is given to the system when they enter the site. This information may also come from the operator. The system therefore has a link to an Identification Data module 118, so that either the user may enter their unique identifier or it may be automatically retrieved. Once logged in, the user is presented with a Welcome Screen, which is a system-generated, user-specific textual comment. The system transforms user activity statistics into text using sentence templates and a set of substitution rules. For example, if a user logs in everyday and contributes to the system the user may be greeted with the following Welcome Screen: "Welcome back UserlOO, you were our top Reporter yesterday and you are in the running for the Reporter of the month!" The WAP browser also drives a Trusted List Editor module 103, which allows the user to view, add, or remove Trusted Reporters from their Trusted List. The Trusted List Manager module 115 is the software module that executes the commands received.

The WAP browser also drives a Feedback Collector module 104, which allows a user to enter their opinion about a piece of information that they may have just read or received in the past from another user. All feedback on reports submitted by users is taken into account in rating a Reporter by the User Rating Engine module 31, which is effectively the user rating unit 31 of Fig. 2.

The WAP browser also drives a Report Collector module 105, which allows the user to make a report on a particular subject area. An Interface Generator module 110 determines the appropriate pages / templates to serve to the user in dependence on the subject area being reported upon. For example, if the level of traffic on the M25 is the subject to be reported upon, then a page / template with the following questions and menu choices may be sent to the user: How heavy is the traffic? - Very heavy, not too heavy, light, etc.

How fast are you moving? - Fast, slow, stopped, etc.

How long has the trip been from the city centre? - 20 min, 15 min, 10 min, etc.

The WAP browser also drives a Reader module 106. This module is similar to the Report Collector; it allows the user to read reports on a subject area on predefined pages, served to the user via the Interface Generator module 110. The WAP browser also drives the Alert Register/Chat Interface module 107, which has two major roles. Firstly, it allows the user to establish an alert on the system so as to receive an up-to-date report on a particular subject area. The user may specify a price and/or time range as part of the alert (e.g. a user wants a "Tell me at" traffic report for the M25 for 7.00 - 7.15pm and is willing to pay 50p). Similarly, existing alerts are posted beside the relevant subject area. Secondly, it allows the user to initiate, continue, or terminate a series of electronic "chat" messages with other users. This is possible through an interface with the chat manager section of the Event/ Alert Broker + Chat Manager software module 33, which is linked to a third party Messaging (e.g. SMS/email) centre 120.

The browser drives a Search module 108, which searches for a subject area. To either read reports or make a report, users can select the subject area and topic that they wish to view (e.g. Traffic/the M25/how busy it currently is). Subject areas are selected through the Directory Engine module 112, which interrogates the subject area section of the Database 114.

Finally, there is the Alter/Suggest Subjects module 109, which allows users to suggest additional subject areas that could perhaps be included on the system's list of available subjects. System administrators review suggestions and the master subject list is centrally altered to include new subject areas via the Subject Engine 113. The option may also be given to users to remotely enter new subject areas via their browser.

Message rating engine

Turning now to the primary modules in the server 16, the Message Rating Engine 30 is designed to produce message ratings based on submitted scores and reports. The message ratings for a subject are stored in the relevant set of message records 26-29. As a message/report proceeds through the Message Rating Engine, it triggers a number of events. First, the User Rating Engine 31 is notified of alterations to individual Reporter's Trust Ratio. Next, the screened report is sent to the Report Reservoir module 111. Then an alert is sent to the Event Broker section of the Event/ Alert Broker + Chat Manager module 33. And finally, details of the screened report are sent to the User Profiler/Group Identifier module 32, which attempts to match like-minded individuals through collaborative filtering.

There are two parts to the Message Rating Engine - abuse software and the content filter.

Abuse software

All raw information is routed through the anti-abuse software, which effectively screens out information that is abusive or mischievous. For both RTR and CR, a number of methods are used to ensure the integrity of the information submitted. First, software that detects the use of vulgar or offensive language can be used. Second, it is physically impossible to visit a large number of venues/contribute news stories in a single day, so each Reporter is limited in the number of reports that they can submit. Third, suspicious spikes in activity will be monitored - e.g. a restaurant which usually receives 10 reports per night but is now receiving 100. Users who are deemed to be abusing the system or are legitimately complained about by other users will have their Trust Ratio reduced.

There are two other ways of checking the validity of information submitted to the RTR system - time and location. Given the real time nature of RTR, time sensitive reports submitted outside the appropriate time period can be detected using the Time module 116. Similarly, location sensitive reports that are submitted from an unrelated location can be detected. For example, if a request for a report on how busy the traffic is in Dublin at 5.00pm is answered by a person in Cork at 5.00pm or a person in Dublin at 4.00pm, then it is evident that these reports are not valid. Location information is obtained from the mobile operator (location checking) via the Location Data module 119; alternatively, this may be obtained direct from the user if their handset is capable of independently determining location, for example if it uses GPS.

Content filter

Turning to the content filter, for each subject there is a set of ratings, which will be dependent on the subject; for restaurants, for example, the ratings may be for service, food, and decor. In CR, the user submits a report on a venue/item which comprises an overall rating/score for the venue based on set criteria (e.g. service, food, cost) and if they so desire, an additional detailed/personal report (e.g. "I enjoyed the seafood very much"). The simplest form of calculation is simply to calculate the average of the ratings given by reporters. However, a number of other inputs, such as the Trust Ratios of the reporters, are preferably also used. The content filter will convert non-numerical data into numerical form. For example, a user may report on a restaurant as follows: Service = excellent, Food = good, Decor = poor. The module assigns a numeric value to each of these descriptions and combines these values with other ratings for this restaurant. The ratings may conveniently be values out of 10 - for example

Pizza Place: Service = 8 Food = 6 Decor = 3.

When a Reporter submits a rating/score for a venue, that score is first normalized with respect to that user's scoring predilection. Both the normalized and actual scores are stored. However, before the normalized score is incorporated in the venue's overall average, it is weighted according to the Reporter's Trust Ratio. A summary rating/score is calculated for a venue based on the reports submitted at that point in time. This is in effect an aggregate rating on the standard of the venue in question. The summary rating for a venue is displayed along with any additional detailed personal reports submitted by Named Reporters.

Consensus reports

In RTR, the user submits a report on a particular subject area which, given the real time nature of RTR, is typically factual and relevant for a point in time. This contrasts to CR, where the user's report is opinion based and influenced by a user's personal preferences. Hence, normalizing inputted data to dilute individual predilections is not an issue. However, the need to produce a summary consensus view of Reporters' opinions is often necessary where a number of users report at the same time. This is achieved by the RTR consensus reporting feature.

Consensus reports allow the system to generate a single combined result from a number of submitted reports. This is also a quality control technique, as the consensus result will highlight any incorrect reports submitted. When a report on a subject is received, it is time stamped by module 116 and remains open for a predefined period of time (e.g. 5 minutes). As additional reports are received, they are accumulated and the consensus report derived. The Trust Ratios of the relevant Reporters are taken into account in weighting their individual reports to form the consensus. The report result is published as a Consensus report, which is therefore not attributable to a single Reporter (the individual reports may be published with a flag indicating whether they are in or out of the consensus). The Trust Ratio (TR) of the highest Reporter in the consensus group is indicated. The monetary reward, if any, is shared among the group, but each member's Trust Ratio is credited for the valid report. If no additional reports are received within this time period, the original report is published on the site as an individual report and a single Reporter is therefore rewarded.

Suppose for example that a request is submitted for details of the traffic on the M25 between 7.00pm and 7.10pm and the user is willing to pay £1. The first report is received at 7.00pm, four more are received up to 7.05pm, and a final report is submitted at 7.07pm, the details of which are as follows:

Time Trust Ratio Report

Reporter 1 7.00 80% Heavy

Reporter 2 7.01 50% Heavy

Reporter 3 7.02 25% Light

Reporter 4 7.03 50% Heavy

Reporter 5 7.04 75% Heavy

Reporter 6 7.07 95% Jam

Assuming the predefined "open" period is 5 minutes, the reports from Reporter 1-5 would be included in a consensus report with a "Heavy traffic" result despite Reporter 3's "Light" report (low TR did not influence weighted average). Reporter 3 would be deemed to have input an invalid report and have their TR reduced via the User Rating Engine 31. Two reports would be published - a consensus report (Reporter 1,2,4,5) and an individual report from Reporter 6. The user would decide which report to read (probably Reporter 6 with the 95% TR and the fact that it is the most up-to-date) and the £1 would be distributed to Reporter 6. However all Reporters (except Reporter 3) would have their TRs increased through the awarding of Usage Points by the User Rating Engine.

Trust Ratio calculation

The main function of the User Rating Engine 31 is to calculate the Trust Ratio for a Reporter. As each Reporter is identifiable and unique, the system is able to categorize the standard or quality of an individual Reporter, which is represented by their Reporter Trust Ratio (0% for wholly untrustworthy, 100% for wholly trustworthy).

The Trust Ratio may be used to determine how much reward a Reporter may receive for submitting a report and may reflect access rights to certain features of the system. For example, only reporters above a certain level may be permitted to provide reports in a "Tell me now" situation. Reporters will be able to view their own Trust Ratio and possibly its workings. The system will classify Reporters on the basis of their respective Trust Ratio - for example, Bandit (0% to 15%), Rookie (40%-60%), Ace (80%- 100%) and so on.

The User Rating Engine calculates the Trust Ratio. The simplest form of calculation is simply to determine the average of the ratings given to that reporter by other users. However, a number of other inputs, such as past performance, frequency of reports, average report rating, time & location, and feedback from other users, are preferably also used. A Reporter's Trust Ratio is updated every time an action is performed which relates to them; such actions consists of the Reporter submitting a report, another user reading the report and giving feedback, etc. A revised Trust Ratio is calculated by a suitable algorithm and is notified to the Rewards Engine module 34 and the Message Rating Engine module 30. This Trust Ratio is stored in the Reporter's (user's) record 23. As mentioned, a Reporter's Trust Ratio is calculated differently depending on the system mode in use - CR or RTR. CR Trust Ratio

For this, the TR is calculated from an average of four numbers, each of which has a value between 0 and 1:

(1) How often the Reporter submits reports; (2) How 'balanced' the Reporter's ratings are;

(3) How many different venues are visited; and

(4) How useful a Reporter's comments are deemed to be by other users.

Each value in the calculation of the Trust Ratio for a CR Reporter is also given a weighting which will reflect the relative importance of each attribute in what the system believes to be a highlyΛowly ranked Reporter. A typical example of values and weightings is as follows:

(1) frequency value = 0.2, weighting = 20%

(2) balance value = 0.5, weighting = 30%

(3) variety value = 0.3, weighting = 10% (4) usefulness value = 1 , weighting = 40%.

This weighting reflects the system's view that a Reporter who submits a limited amount of very useful reports is more highly valued then a Reporter who submits a large number of not very useful reports. The Trust Ratio is then calculated as: [(0.2 x 0.2) + (0.5 x 0.3) + (0.3 x 0.1) + (1 x 0.4)] = 0.62, i.e. a 62% Trust Ratio.

The four components of the CR Trust Ratio calculation are determined as follows (all values are configurable within the present system):

(1) How often the Reporter submits reports (frequency). This component represents a Reporter's activity. Reporters who report more often have a higher value and therefore a higher overall Trust Ratio. The value is calculated on the basis of the number of Reports submitted in the last x days from the date the Reporter starts divided by the number of expected reports in the last x days. For example, suppose that a Reporter submitted 8 reports in the last 20 days. If 8 reports are expected in a 20 day period, therefore the value calculated equals 1 (8/8). Similarly, if a Reporter makes 4 reports in last 20 days and 8 reports are expected in a 20 day period, therefore the value calculated equals 0.5 (4/8). The expected number of reports is set to the maximum expected number, and the calculated value is limited to 1, so that even if a Reporter submits twice as many reports as this maximum, the calculated value does not exceed 1.

(2) How balanced the user's ratings are (balance). To judge how balanced the user's scores are, the system looks at their average un-normalised ratings submitted by the Reporter. On a scale of 0 to 1, 0 is extremely unbalanced and 1 is excellently balanced. Over time it is assumed that the user's average score will be 0.5 or neutrally balanced. Therefore the value is calculated using the following formula:

User rating balance = 1 - (difference (0.5, Average rating) * 2). For example, if a Reporter's average rating is 0.7, then the Reporter's rating balance is 1 - (0.2 x 2) = 0.6. Similarly, if a Reporter's average rating is 0.2, then the Reporter's rating balance is 1 - (0.3 x 2) = 0.4.

(3) Number of different venues visited (variety). The value is calculated on the basis of the number of venues rated in the last x days from the date the Reporter starts, divided by the number of expected venues to be rated in the last x days. Say again it is believed that reporting on 8 different venues in the last 20 days constitutes a very strong performance. The value is defined by the following formula:

Minimumj 1, (Number of different places reported in last Y days)/(Maximum number of reports expected in Y days)}. For example, if a Reporter submits reports on 4 venues in the last 20 days, the value calculated equals Minimum(l , 4/8) = 0.5.

(4) How useful a Reporter's comments are deemed to be by other users (usefulness). It is assumed that feedback received on reports uses a simple 2-valued (binary) scale; that is, reports are rated as being either "Useful" (1) or "Not Useful" (0). At the start, every Reporter would be assigned a default "Usefulness value" of say

0.5. This value is adjusted up or down according to the feedback received from other users on the reports submitted by the Reporter (i.e. the number of useful/not useful ratings received). In calculating the Usefulness Value, a Usefulness Coefficient (UC) is used. Every time someone finds a reporter's report to be "Useful", 1 is added to the reporter's UC; if they deem the report "Not useful", 1 is subtracted from the UC. Clearly, the value can be positive, negative or 0. Every Reporter is a UC of 0 at the beginning. The Usefulness Value is calculated as follows: If UC > 0, then Usefulness Value = 0.5 + 2 * (UC/UC_Maχ) If UC < 0, then (Usefulness Value = 0.5 + 2 * (UC/UC_Min) where UC_Ma = Highest UC value of any Reporter in the group

UC_MIΠ = Lowest UC value of any Reporter in the group. For example, suppose that there are five Reporters in a group, Reporters 1 - 5:

Reporter No. Useful No. Not Useful UC

Reporter 1 5 3 2

Reporter 2 0 0 0

Reporter 3 0 5 -5

Reporter 4 6 0 6

Reporter 5 2 5 -3

Thus UC_Max = 6 (Reporter 4), UC_Min = -5 (Reporter 4). For each Reporter, the Usefulness Value would be calculated as follows:

UV Reporter 1 = 0.5 + [(2 / 6) x 0.5)] = 0.6667

UV Reporter 2 = 0.5 + 0 = 0.5

UV Reporter 3 = 0.5 - [(-5 / -5) x 0.5] = 0

UV Reporter 4 = 0.5 + [(6 / 6) x 0.5] = 1 UV Reporter 5 = 0.5 + [(-3 / -5) x 0.5] = 0.2

As expected, Reporter 3 is the most negatively balanced Reporter, Reporter 2 neutral and Reporter 4 the most positively balanced Reporter.

RTR Trust Ratio The RTR Trust Ratio is calculated from a weighted average of two numbers, each of which has a value between 0 and 1: (1) How often a Real Time Reporter submits reports (frequency)

(2) A Real Time Reporter's Usage Score (US).

As with the calculation of the Trust Ratio for a CR Reporter, the weighting of each value in the calculation of the Trust Ratio for a RTR Reporter will reflect the relative importance of each attribute in what the system believes to be a highly/lowly ranked Reporter. For example, the Trust Ratio could be calculated according to the following relative weighting:

(1) Frequency = 0.4, weighting = 40%

(2) Usage Score = 80 points or 0.80, weighting = 60%. The Trust Ratio is then calculated as

(0.4 x 0.4) + (0.8 x 0.6) = 0.64, or a 64% Trust Ratio This weighting again reflects the system's view that quality of the information submitted is more important then quantity. However, a combination of both is essential to gain an above average Trust Ratio. The frequency value for "How often a Real Time Reporter submits reports" is calculated in a similar fashion as the previously illustrated calculation of the frequency value for "How often a Continuous Reporter submits reports". Reporters who report more often have a higher value and therefore a higher overall Trust Ratio. The value is calculated on the basis of the number of Reports submitted in the last x days from the date the Reporter starts divided by the number of expected reports in the last x days. Even if a Reporter submits twice as many reports as the maximum expected, the calculated value is limited so that it does not exceed 1.

The Usage Score (US) for a Real Time Reporter is a measure of the Reporter's participation and performance in the system. The number of Usage Points a Reporter accumulates over time represents this. A reporter making a valid report gains Usage Points, points are deducted for incorrect reports. The Usage Point value ranges between 0 and 100, which are the minimum and maximum values respectively. For example, the following table could apply in relation to points added and deducted: User activity in system Points adi ded Points deducted

For valid report for invalid report

Submit consensus report 1 -3

Submit individual report 3 -3

Reply to "Tell me when" request 5 -6

Reply to "Tell me now" request 5 -10

Abusing the system 0 -10

As a Reporter's Usage Points accumulate, the system has the ability to apply a sliding scale allocation of points, thereby ensuring that while it may be relatively straightforward to achieve an average level of Usage Points, it becomes more difficult to build a high level of points. This ensures that highly active and loyal users of the system are recognised as such in terms of Usage Points.

Dealing with Feedback/Complaints

Capturing user feedback on reviewed reports is an essential element to the operation of an effective information exchange in RTR. The User Rating Engine receives user feedback via the Feedback Collector 104. However, complaints have to be dealt with carefully, as they have a significant impact on a Reporter's Trust Ratio. Each complaint must be examined to ensure that it is valid and sincere and not the work of an unscrupulous user who continually complains. If a report is a Consensual Report then it is unlikely that the complaint is genuine, as the Consensual Reporters would have had to orchestrate the invalid report. Likewise, if the report was read by a lot of people and only one complained, this complaint should be treated with suspicion. If, on the other hand, a flurry of complaints is received about a report (a

Consensual Complaint, if you will), this lends credence to the suggestion that the report is invalid. In terms of policing the complaints procedure, there are three key features incorporated in the system: (i) When a user reads a report in RTR there is a limited time period within which a complaint may be accepted - the Complaint Zone (RTR only). (ii) Complaints are recorded so that individual serial complainers are detected

(RTR + CR). (iii) Complaints are recorded so that organised groups of abusers are detected

(RTR + CR). (iv) A user who complains about a reporter will not receive a report from that user for a configurable amount of time. This is called the "broadcast and reception information filter".

(i) Complaint Zone In RTR, the Complaint Zone commences at the time a report is submitted and finishes after a predefined period - e.g. 1 hour. This is the time period within which complaints will be accepted for this type of report; complaints are discarded automatically if they are outside this range. Therefore users who complain too early or too late will be at best disregarded and at worst penalised. For CR, the Complaint Zone is irrelevant; venue ratings are not as time sensitive as RTR news, as they exist for extended time periods.

A Complaints Threshold is used, representing a critical mass of negative feedback - i.e. a large enough percentage of the users who viewed the report believe it to be invalid. The level at which the Complaints Threshold is set depends on the type of report involved. For Consensus Reports this may be in the range of say 60% and for Individual Reports this would be lower (e.g. 40%).

Mathematically, a zone ranging from 100% to 0% at the start and end points of the time period can be used to determine whether the Complaints Threshold is reached. The zone has a look-up array of values, each of which corresponds to a section of the complaint zone. This array is logarithmic so that look-ups may be either linear or non-linear. The time of each complaint is logged and the corresponding array value stored and added to any existing complaints. If the calculated total of the aggregated complaints exceeds the Complaints Threshold, then the report is deemed invalid. Suppose for example that 10 users read an Individual Report at 8.00 and 6 of them complain as to the accuracy of the report at the following times: Time 8.00 8.15 8.30 8.45 9.00

No. of users complaining 1 4 1

Array Value 1.0 0.8 0.4 0.1 0

Complaint Value 1 3.2 0.4

Aggregate Complaint Value 1 4.2 4.6 4.6 4.6

As the aggregate complaint value of 46% (4.6/10.0) exceeds the predefined Complaints Threshold of 40%, the report is therefore deemed invalid. This triggers a number of possible actions including: All money is refunded to the users who purchased the report, all subsequent reports from the offending Reporter will not be offered to these particular users for a period of time, and the offending Reporter will lose Usage Points, thereby lowering their Trust Ratio.

(ii) Individual abuse of complaints facility As all complaints are logged by the system, it is relatively straightforward to track users who have an above average tendency to complain. If the complaints are valid then this is not an issue, but if the complaints are malicious then the user is abusing the system. For RTR, individual invalid complaints will by and large fail to exceed the Complaints Threshold and be recorded as invalid complaints made by a unique user. A user who has made say at least 3 complaints, the majority of which are invalid, is viewed as abusing the complaints facility and therefore penalised by having their Trust Ratio reduced.

(iii) Group abuse of complaints facility Concerted abuse of the complaints facility by a group of users is more difficult to detect and requires incorporating more elaborate avoidance procedures into the system. The procedures centre on the fact that consistent group abusers will typically comprise the majority of a group of users complaining and that this will be replicated by the abusing group at another time or in another subject area. Every time a Complaints Threshold is exceeded and a series of is deemed to be valid, the users in the complaining group are recorded. Subsequent complaining groups are compared to the recorded groups in the database to see if a group of users are attempting to submit bogus complaints. A group of users will be deemed to be abusing the complaints facility and all members of the group will have Usage Points deducted if the following conditions are met: (a) The current complaining group has exceeded the Complaints Threshold;

(b) The current complaining group is approximately the same size as a previous sample group (say within ±20%);

(c) a given fraction (say 80%) of the users in this group were in the previous sample group.

(iv) The broadcast and reception information filter

Users who complain about reports submitted by other users are no longer presented with reports from those particular individuals and vice versa. In other words, the user's experience of the exchange is customised to exclude contributions from individuals they disagree with. Similarly, reports from the complaining user are no longer presented to the guilty party. This is achieved through links with the Report Reservoir module 111 and the Event/Alert Broker + Chat Manager module 33. The broadcast and reception information filter in the latter module (discussed below) ensures that the two individuals no longer interact with each other, in terms of the exchange of electronic messages, should this be requested. Thus one user can be hidden from another (and usually vice versa).

Event/alert broker and chat manager

A further primary software module is the Event/Alert Broker + Chat Manager 33. This module fulfils three important roles - triggering alerts, managing the exchange of electronic chat messages, and managing the creation and distribution of "News Mail" electronic messages to selected users. It forms part of an intelligent mail relay software subsystem, linked to the SMS/email server, which manages the transfer of messages between users. Event/Alert Broker

This module manages the establishment of and reply to user requests such as Time alerts (Tell me at), Event alerts (Tell me when), and One-to-One interaction (Tell me now). A user uses the Alert Register 107 to register a request to alert them when a report on a particular subject area is submitted. The Event Broker module is kept up-to-date on reports entering the system, and matches them to users with related requests. Users are alerted to relevant up-to-date reports via electronic messaging such as SMS/email via the mobile operator's messaging module 120. Once the alert is received, a user can then enter the system and retrieve the report or have it sent directly to them.

Chat Manager

This module also facilitates the exchange of electronic chat messages between users while protecting each user's identity and privacy. This is achieved using an intelligent electronic message relay, which is linked to a SMS or SMTP based email server, for example. This allows users to send and receive electronic messages to/from selected users without revealing personal details such as name, email or phone number. In addition, a user can decide to cease an exchange of messages with another user. This may be due to lack of interest or personal reasons. The user has the option to permanently terminate interaction with a user, if they so desire. As mentioned previously, this is achieved through the use of a "broadcast and reception information filter". As all interactions are tracked, it is possible to ensure that two individuals no longer interact with each other should this be requested. Therefore users have the ability to decide who has access to the information they submit and who has the ability to interact with them.

Anonymity is achieved by using system-based alias email addresses which mask users' actual email/phone numbers. This masking occurs at registration when a user inputs their actual email address/phone number (e.g. User@personal.com) and selects a unique user identification (userlD) such as ReporterlOO. From that point onwards the system associates the unique userlD (ReporterlOO) and userlD contact reference (e.g. Reporterl00@system.com) with the recorded user contact details. When an electronic message exchange takes place, the system automatically knows that the message to the displayed useriD and associated contact reference (ReporterlOO@system.com) should be relayed to the correct contact details of the user (User@personal.com). Therefore upon arrival at the system's mail server, the electronic message, which is in a standard format such as SMTP, proceeds through 5 steps: (i) The message is reviewed by the software module, the recipient's contact reference (ReporterlOO@system.com) is isolated, and a look-up performed to the database, which returns the correct userlD for the recipient (ReporterlOO); (ii) A similar procedure is used to determine the sender's userlD (e.g.

Reρorter200); (iii) The system then checks to see whether the message recipient has stated that they do not want to receive electronic messages from this particular sender; (iv) If the message is from a "barred" user then it is not delivered to the recipient; (v) Jf not then the message is relayed to the intended recipient.

The sender's anonymity is maintained, as the system ensures that only the sender's system contact reference (Reporter200@system.com) is included.

"News Mail" Electronic Messages News Mail messages are electronic messages automatically sent to users, particularly active users (those who contribute information to the exchange). The messages summarise information submitted by other users, ie the activity on the system, on subjects/venues that may be of interest to the user - for example, bars close to the user's current location. A typical message might be "Based on reports submitted, Big Bar is the most popular bar tonight in Metropolis (hyperlink to the latest RTR report), the most popular bar near you is the Snug Bar (hyperlink to the latest RTR report), etc.". In effect, News Mails are pre-configured system generated reports which summarise activity in the system in addition to providing information on subjects/venues near a user's location. The data for these reports is obtained from the message database 22, which contains the various reports submitted by users 10 through the system's Add Information software module 37. User activity in the system determines which users receive a News Mail.

The News Mail system uses a natural language generator. This system is a completely automated process, which gives the user the perception of personality and dynamism to the system. This is used in a number of areas. The software code observes user activity and presents personalised messages to users when they enter the system or perform a certain activity. For example, if a user does not visit the exchange for two weeks, upon their return they can be presented with the message "Welcome back - we have not seen you for a while!". The software also transforms the reports submitted by users into a more intuitive, user-friendly sequence of text using sentence templates and substitution rules.

The structure of the News Mail is configurable; for each user, a predefined template contains dynamic content that can be tailored to that user. The News Mail may provide direct links to distinct items of information in the exchange via hyperlinks in the electronic message. The News Mail management module is linked to a location-based information source to enable the tailoring of the content based on the current or intended location of the user.

A user's location is kept up to date as far a possible. In the absence of other information, this generally means taking their location as the location of the last submitted report on a subject/venue or via the Location Data module 119. Combining the News Mail element of module 33 with the location data module 119 would result in more accurate and up to date location information about a user. Therefore the system generated News Mail can be tailored more accurately to their actual current location. For example, the following News Mail could be produced; "Based on reports submitted, the Big Bar (hyperlink to latest RTR report), which is 4.5 miles from you is the most popular bar tonight in Metropolis. The Fun Bar (hyperlink to latest RTR report), which is 200 metres from you, is nearly as popular".

In summary, the News Mail element of the software module 33 intelligently manages the collation of data into pre-configured report formats based for example on a user's location, and ensures their distribution as electronic messages to selected users via the Messaging module 120. Further modules

A further primary software module is the Intelligent User Profiler/Group Identifier module 32. This is an intelligent software module that attempts to match like-minded individuals, based on the subject areas they request and report on. The interest of users in reading reports on certain subject areas is tracked through a link with the Report Reservoir module 111. Similarly, their interest in submitting news on certain subject areas is tracked through activity in the Message Rating Engine module 30. Matching like-minded individuals relies on analysing user activity trends in particular subject areas using techniques such as collaborative filtering (e.g. a user who frequently reports on heavy traffic on the M25 could be suggested for adding to the Car Pooling news subject area). Suggestions so generated are sent to the user via the Reader module 106; the user can then decide whether or not to act upon the suggestion. Similarly, the User Profiler may suggest the addition of like-minded Reporters to a user's Trusted List, via the Trusted List Manager module 115. The Rewards Engine 34 calculates the charges made, if any, to users of the system. The charges may include standing charges and/or usage charges. Usage, in this context, will normally mean primarily the amount of information read from the system, since that is the primary benefit which users gain. It is desirable to encourage users to enter information into the system, so the entry of information will normally be free or incur very low costs. Preferably the rewards engine calculates rebates or monetary rewards, if any, for users entering information. The size of the reward can be calculated in dependence on such factors as the number of times that a report is read by other users and what their Trust Ratio is.

The rewards engine may include a linkage to a mobile operator's billing system via the Reward/Billing Manager 117, so that the operator of the present system can collect the fees charged or distribute monetary rewards to users of the present system via a user's monthly phone bill. In the future, this may involve the deduction of a "cash" payment from a mobile phone smart card or similar technology when this becomes more commonly used. The server 16 also includes various secondary modules. A Report Reservoir module 111 manages the addition and extraction of news from the Database module 114. The Report Reservoir in effect acts as the system cache for current reports and archives less popular, out-of-date reports.

A further secondary module is the Trusted List Manager module 115, which manages the addition and deletion of Reporters onto a user's Trusted List. It also manages user interaction with suggested Trusted Reporters (like-minded individuals) generated by the Intelligent User Profiler/Group Identifier module 32.

Claims

Claims

1 An information dissemination system comprising at least one set of message records, a set of user records, means for a user to add data to a set of message records, and means for a user to read data from a set of message records, characterized by rating means for determining, for each user submitting messages, a rating dependent on the quality of those messages.

2 A system according to claim 1 wherein the quality of a message is determined from objective characteristics of the message.

3 A system according to claim 1 wherein the quality of a message is determined from subjective characteristics of the message comprising rating comments from other users who read the message.

4 A system according to claims 2 and 3 wherein the ratings of the users are linked with the messages those users submit.

5 A system according to claim 4 wherein the rating of a message is attached explicitly to the message by being presented to a user who reads the message.

6 A system according to claim 4 wherein the rating of a message is attached implicitly to the message.

7 A system according to claim 1 wherein the rating means comprise user rating means for recording, for each user, rating values for other users.

8 A system according to claim 1 wherein there is a plurality of sets of message records, one for each of a plurality of different subjects. 9 A system according to claim 8 including means for a user to register an interest in a set of message records, i.e. a subject, the system thereupon sending to that user an alert signal relating to messages relating to that subject.

10 A system according to claim 9 including means for then enabling a user registering an interest in the subject and a user providing a message relating to that subject to communicate with each other on a one-to-one basis.

11 A system according to claim 1 wherein the system records messages from users which can be transmitted substantially direct to other users as data, and also compiles summary information from a plurality of messages received from users for transmission to other users as data.

12 A system according to claim 1 including means for recording, for each user, a user profile indicating the user's assessment of other users as information providers, and means for automatically matching a user profile with other user profiles and, on finding a reasonable match, giving the user the option of modifying their profile in the light of the other user profiles.

13 A system according to claim 1 and arranged to operate in two modes, a Continuous Rating mode for non time sensitive information and a Real Time Reporting mode for time sensitive information.