EP1334449A2 - Systeme de traitement de donnees - Google Patents

Systeme de traitement de donnees

Info

Publication number
EP1334449A2
EP1334449A2 EP01938509A EP01938509A EP1334449A2 EP 1334449 A2 EP1334449 A2 EP 1334449A2 EP 01938509 A EP01938509 A EP 01938509A EP 01938509 A EP01938509 A EP 01938509A EP 1334449 A2 EP1334449 A2 EP 1334449A2
Authority
EP
European Patent Office
Prior art keywords
user
users
message
reporter
rating
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP01938509A
Other languages
German (de)
English (en)
Inventor
Cathal Sheridan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Newsymphony Technologies Ltd
Original Assignee
Newsymphony Technologies Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Newsymphony Technologies Ltd filed Critical Newsymphony Technologies Ltd
Publication of EP1334449A2 publication Critical patent/EP1334449A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • 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.
  • WAP Wireless Application Protocol
  • 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).
  • IRC Internet Relay Chat
  • 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.
  • the present system is concerned primarily with providing "non digital" information, anywhere and at any time, to distinct groups of wireless Internet users
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • CR Continuous Rating
  • RTR Real Time Reporting
  • 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.
  • the Trust Ratio is calculated differently for each mode, due to the emphasis on different performance traits of reporters in RTR and CR.
  • 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).
  • 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.
  • 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.
  • Named Reporters 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.
  • 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
  • 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.
  • Reporter may belong to various classifications - an individual Reporter could be both a Named and an On-the-Spot Reporter, for example.
  • 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.
  • 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.
  • 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".
  • 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.
  • RTR 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • WML pages for example (WAP version of HTML pages)
  • SMS for example
  • 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.
  • 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 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.
  • 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.
  • 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).
  • 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).
  • 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.
  • 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.
  • subject name e.g. Bistro Cafe or M25 traffic
  • attribute e.g. cafes and restaurants or traffic
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Tell me when/Tell me at
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Alter/Suggest Subjects module 109 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.
  • 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.
  • the Message Rating Engine it triggers a number of events.
  • the User Rating Engine 31 is notified of alterations to individual Reporter's Trust Ratio.
  • the screened report is sent to the Report Reservoir module 111.
  • an alert is sent to the Event Broker section of the Event/ Alert Broker + Chat Manager module 33.
  • 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.
  • All raw information is routed through the anti-abuse software, which effectively screens out information that is abusive or mischievous.
  • a number of methods are used to ensure the integrity of the information submitted.
  • 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.
  • 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.
  • 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").
  • set criteria e.g. service, food, cost
  • 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.
  • 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
  • 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.
  • 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.
  • a report on a subject 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.
  • 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:
  • 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.
  • 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
  • the TR is calculated from an average of four numbers, each of which has a value between 0 and 1:
  • 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 four components of the CR Trust Ratio calculation are determined as follows (all values are configurable within the present system):
  • 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.
  • UC Usefulness Coefficient
  • 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 3 is the most negatively balanced Reporter, Reporter 2 neutral and Reporter 4 the most positively balanced Reporter.
  • 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)
  • 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.
  • the Trust Ratio could be calculated according to the following relative weighting:
  • 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.
  • the following table could apply in relation to points added and deducted: User activity in system Points adi ded Points deducted
  • 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.
  • the User Rating Engine receives user feedback via the Feedback Collector 104.
  • 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
  • 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.
  • 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%).
  • 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.
  • 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
  • Event/Alert Broker + Chat Manager 33 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.
  • 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).
  • userlD unique user identification
  • Reporterl00@system.com userlD contact reference
  • 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.
  • 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 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.”
  • 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".
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Game Theory and Decision Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La présente invention concerne un système de diffusion d'informations fonctionnant principalement via l'Internet sans fil et des téléphones mobiles. Ce système comprend deux ensembles de sujet et d'enregistrements de message (26, 27) (pour rapport en temps réel RTR), et (28, 29) (pour rapport continu CR), un ensemble d'enregistrement (23) utilisateur, un organe permettant à un utilisateur d'ajouter des données aux enregistrements de message, et un organe permettant à un utilisateur de lire des données issues de ces enregistrements de message. Un organe de notation (31) détermine pour chaque utilisateur qui soumet des messages, une note en fonction de la qualité (subjective, par exemple les informations en retour des autres utilisateurs et/ou objective) de ces messages. Un utilisateur peut inscrire un intérêt pour un sujet, et recevoir ensuite des signaux d'alerte relatifs à de nouveaux messages concernant ce sujet, puis il peut communiquer directement avec d'autres utilisateurs. Ce système détermine aussi des profils utilisateur et rapproche des utilisateurs avec des profils similaires.
EP01938509A 2000-07-07 2001-06-01 Systeme de traitement de donnees Withdrawn EP1334449A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
IE20000553 2000-07-07
IE000553 2000-07-07
PCT/IE2001/000074 WO2002005115A2 (fr) 2000-07-07 2001-06-01 Systeme de traitement de donnees

Publications (1)

Publication Number Publication Date
EP1334449A2 true EP1334449A2 (fr) 2003-08-13

Family

ID=11042642

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01938509A Withdrawn EP1334449A2 (fr) 2000-07-07 2001-06-01 Systeme de traitement de donnees

Country Status (3)

Country Link
EP (1) EP1334449A2 (fr)
AU (1) AU2001264183A1 (fr)
WO (1) WO2002005115A2 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10305771A1 (de) * 2003-02-11 2004-08-19 Hubertus Von Savigny Verfahren zur Erbringung von Dienstleistungen über ein Kommunikationsnetz
GB201715423D0 (en) * 2017-09-22 2017-11-08 Nchain Holdings Ltd Computer-implemented system and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0205115A2 *

Also Published As

Publication number Publication date
AU2001264183A1 (en) 2002-01-21
WO2002005115A8 (fr) 2003-05-30
WO2002005115A2 (fr) 2002-01-17

Similar Documents

Publication Publication Date Title
US7970648B2 (en) Advertising campaign and business listing management for a location-based services system
US20080052639A1 (en) Method and System for Providing Personalized Menu Page in Wireless Internet
CA2683555C (fr) Systemes et procedes pour faciliter des recherches par l'intermediaire d'un reseau social
KR101059044B1 (ko) 이동 장치용 위치 기반 사회적 소프트웨어
US20050086211A1 (en) System and method for searching, finding and contacting dates on the Internet in instant messaging networks and/or in other methods that enable immediate finding and creating immediate contact
US20040122810A1 (en) System and method for searching, finding and contacting dates on the Internet in instant messaging networks and/or in other methods that enable immediate finding and creating immediate contact
US20170097937A1 (en) Populating a Database in a Communication System
US9159110B2 (en) System and method for propagating inquiries and answers thereto through on-line human network
WO2005116873A1 (fr) Systeme de recherche de contenus permettant de fournir des contenus fiables sur un reseau et procede associe
US20050220280A1 (en) System and method for rating alternative solutions
WO2006129923A1 (fr) Procede d'acces et de transmission a des/de contenus mobiles au moyen d'un message hyperlien, serveur de fournisseurs de communications mobiles et serveur de fournisseurs de contenus appropries
EP1662817B1 (fr) Système et procédé pour fournir des informations relatives à une manière de communiquer
US20090187490A1 (en) System and a method enabling a customer and a business to interconnect via instant messaging in order to complete a business transaction
KR20020092540A (ko) 메신저를 이용한 맞춤정보 제공 방법 및 시스템
WO2002005115A2 (fr) Systeme de traitement de donnees
JP2002041522A (ja) 個人情報開示システム及び電子メール配信システム
CA2513306A1 (fr) Systeme et methode de recherche, de decouverte et d'etablissement de rendez-vous par internet au moyen de reseaux de messagerie instantanee et/ou d'autres methodes donnant des resultats immediats et permettant de creer un contact immediat avec l'autre personne
KR100597279B1 (ko) Ｔｔｓ를 이용한 콜렉트 콜 서비스 제공 방법 및 시스템
US20060242253A1 (en) Method and system for providing TTS collect call
EP2199968A1 (fr) Service laissant les fournisseurs télécharger vers la base de données des demandes anonymes
KR20050080873A (ko) 검색엔진과 통신시스템과의 연동을 통한 정보 검색/제공방법 및 시스템
JP2002092287A (ja) 携帯電話へのメッセージ配信によるリサーチシステム及び方法
KR100838155B1 (ko) 인터넷폰 서비스 제어방법
KR20010104806A (ko) 인터넷을 이용한 질의/답변 방법
KR20050059383A (ko) 커뮤니티의 히스토리 관리 시스템 및 그 방법

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17P Request for examination filed

Effective date: 20031201

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20050104