WO2009125417A2

WO2009125417A2 - Method for screening requests in a communication network

Info

Publication number: WO2009125417A2
Application number: PCT/IN2008/000237
Authority: WO
Inventors: Babu Penumalla Sateesh; Gopalkrishnan Satish; Santakumar Subrahmanian
Original assignee: Onmobile Global Limited
Priority date: 2008-04-09
Filing date: 2008-04-09
Publication date: 2009-10-15
Also published as: WO2009125417A3

Abstract

A method for screening and receiving expert advice in a communication network is disclosed. A user may place multiple requests. The request is served by the request screening system after screening the request. The requests screened to have objectionable content are informed to the user. The acceptable requests are processed further. A response to the acceptable requests is retrieved from a database or received from an expert of the domain. The response received from the expert is updated in the database and sent to the user.

Description

METHOD FOR SCREENING REQUESTS IN A COMMUNICATION

NETWORK

DEFINITIONS

Communication network: Communication network includes, but is not limited to, internet, intranets, Wide Area Networks (WANs), Local Area Networks (LANs), Public Switched Telephone Network (PSTN), Global System for Mobile Communications (GSM) and transducer links such as those using Modulator- Demodulators (modems).

Mobile device: A portable device enabled to communicate with other devices for the transfer of signals. Examples of mobile device include, but are not limited to, voice phone, cordless phone, mobile phone, Personal Digital Assistant (PDA), pager, notebook PC, and ultra-mobile PC.

User: A person who is using communication network for communication.

Request: A query placed by a user over a communication network. The query may be a question seeking details relating to a particular field such as travel, medicine, astrology, news etc. The query may also be for uploading user generated content on a server in a communication network. For example, a user may request the communication network service provider to set a multimedia file uploaded by the user as her ring back tone. Another example could be a user uploading a multimedia file as a performance to be screened by a judge in an automated audition system.

FIELD OF THE INVENTION

The present invention relates to managing requests form users in a communication network. In particular, the invention relates to the screening of requests in a communication network.

BACKGROUND

The improved capability of mobile devices has allowed telecom operators to provide various features to the users of these devices. Multimedia messaging, broadband, wireless internet, roaming services, GPS, alerts, call management, dial- a-service, ringtones, wallpapers, animations, and games are some of the common services provided by telecom operators. Live news related to sports, movie, music and personalized live services like banking, stocks, astrology, dating, and booking tickets are also provide by telecom operators.

Using the services provided by the telecom operator, a user may place a request with the network and receive a response. The request may be a question by the user seeking information of her interest. The requested information may berelated to recent news, scientific facts, health guide, tourism, puzzles, horoscope, jokes etc. The request may be forwarded to the expert of relevant domain who may respond to the request. An example of such request could be a query to obtain information related to disease A. The request can be a set of questions such as 'What are the symptoms of disease A? What precautions should one take when suffering from disease A?'

Another example of the request could be a user sending an SMS to the telecom service provider for her billing related queries. The service provider can assign certain codes to the user for specific queries to be included in the SMS.

Also, a user can request for uploading certain multimedia content on a server provided by the communication network service provider. The uploaded multimedia content may be retrieved from the server when required. An example of such a request would be a user requesting to upload an audio file which may be set as a Ring Back Tone (RBT) when the user receives a call.

United States Publication No. 20040044542, incorporated herein by reference, describes a system for answering the queries of a user of a network. The system includes a knowledge base which can be queried over a network. The system allows a user to query the knowledge base. A match for the query is searched in the knowledge base. The match retrieved is forwarded to the user. When a query results in no matches from the knowledge base, it is forwarded to an expert. After the expert has answered the query, the answer is updated in the knowledge base and forwarded to the user. However, in this case the system is limited to only answering queries and may not address different requests by the user. Further, the system does not have any provision for screening the queries submitted by a user. There could be a scenario in which the request by the user is objectionable and cannot be taken forward to the expert. The request could be related to indecent content or copyrighted content. Due to the wide range of requests such as uploading of audio/video content and requests by users, there is a need for screening the content being uploaded by the users in a communication network.

The existing systems do not provide method for screening user generated content or method for screening requests in general in a communication network. The multimedia file to be uploaded by the user may contain objectionable content. In case of user generated ring back tone, upon receiving a call, the objectionable multimedia content is played by the telecom operator. The user receiving the objectionable multimedia content may feel offended and may register complain against the operator. The multimedia file to be uploaded by the user may contain copyrighted content. Sharing freely such copyrighted content over the network may have legal implications on the operator.

To avoid nuisance and to provide a healthy service to the users a telecom operator needs to screen and filter contents which are uploaded by the users and played to the users. Hence, there is a need for a system in the communication network which can screen the multimedia contents being uploaded by the user.

SUMMARY OF THE INVENTION

According to an embodiment, a method for screening requests in a communication network is disclosed. The method is for receiving a request form a network user, screening the request, tagging the request and processing the request. A user of the network may place a request using her communication device. The communication device may be a mobile phone. The request may be a specific question, a request for uploading a file on the server provided by the communication network service provider or any other form of communication. The request is screened before the communication network service provider responds to the request. The screening is based on predefined criteria. The predefined criteria could be screening the request to filter-out indecent and objectionable requests. Other predefined criteria could be screening the request to filter-out requests for copyrighted content. Based on the screening, the requests are tagged by providing a rating to the request. Depending on the tag, future actions are taken for the request. The tag to the request may include, but is not limited to, numbers, text or any combination thereof. In one embodiment, the request may be tagged as 'objectionable' or 'acceptable' based on the content. The requests which are not objectionable are acceptable. The acceptable requests are taken forward for processing while the users with objectionable requests are informed to take appropriate actions. In an alternate embodiment, the tag is a rating of the request on a scale of 1 to 5, the rating denoting the quality of the requests. For example, when the request is uploading a joke, a rating of 5 may correspond to a good joke while a rating of 1 may correspond to the presence of objectionable content in the request. The requests which are taken forward are processed by first looking for acorresponding response in a database. The user is provided with the response after successfully retrieving a response from the database. When no corresponding response could be found in the database, the request is viewed by an expert. The expert periodically visits the database and provides a response satisfying each query stored in the database. Once a response to a request is provided by the expert, the response is forwarded to the requestor and the same response is updated in the database. Response to such future requests is retrieved form the response database.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic depicting an exemplary communication environment in accordance with an embodiment of the invention;

FIG. 2 is a schematic illustrating a method of screening a request in accordance with an embodiment of the invention;

FIG. 3 is a schematic illustrating request screening system according to an embodiment; and

FIG. 4 is a flow diagram illustrating a method of screening, tagging and processing a request in accordance with an embodiment of the invention. DETAILED DESCRIPTION

In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of the invention. However, it will be apparent that the invention may be practiced without these specific details. Various aspects and features of example embodiments of the invention are described in more detail hereinafter.

A method for screening requests in a communication network is disclosed.

FIG. 1 illustrates a communication environment according to an embodiment of the invention. The communication environment comprises a user 102, a mobile device 104, a communication network 106, and a Request Screening System (RSS) 108. Mobile device 104 may be carried by user 102 of communication network 106. Mobile device 104 and RSS 108 are connected to communication network 106. Communication network 106 can support multiple mobile devices^' 104. The connection between mobile device 104 and communication network 106 is provided by a Communication Service Provider (CSP). Communication network 106 may include different modules for communication, for example, MSC, SMSC, USSDC, and channels of communications like internet, WAP etc. RSS 108 can manage multiple requests from multiple users 102. Further details regarding RSS 108 are provided in conjunction with FIG. 3.

FIG. 2 illustrates a method of screening a request in accordance with an embodiment of the invention. User 102 may connect to communication network 106 via mobile device 104 and place a request. At step 202, RSS 108 receives the request placed by user 102. Thereafter, at step 204, RSS 108 screens the request. The screening may be done based on predefined criteria. The predefined criteria may be specified by an administrator of RSS 108. For example, the predefined criteria may include criteria for checking if the request placed by user 102 is objectionable or offensive. The requests which are not objectionable are acceptable. Further, the request is declined when the request is objectionable and the request is processed when the request is acceptable. In an embodiment of the invention, the screening may rate the request. The ratings may depend upon the quality of the request. The user 102 may be gratified by a reward depending on the rating of the request. Another example of the predefined criteria may include criteria for checking if the request relates to copyrighted content. In an embodiment according to the invention, RSS 108 declines the request when the request relates to the copyrighted content and processes the request when it does not relate to the copyrighted content. Further, at step 206, based on the outcome of screening, the request is tagged. The tag on the request represents the quality of the request. For example, a tag of 5 may correspond to a good quality request while a tag of 1 may correspond to objectionable request. The requests which are not objectionable are acceptable requests. Thereafter, at step 208, the acceptable requests are taken forward for processing. At the end of processing step, a suitable response is sent to user 102.

User 102 may place a request using mobile device 104. Mobile device 104 is equipped with hardware and software features which allow user 102 to place a variety of requests. Example of hardware features may be hardware supporting audio, video and image files. Example of software features may be software applications playing audio and video files. Mobile device 104 may have features like multimedia messaging, broadband, wireless internet, roaming services, GPS, alerts, call management, dial-a-service, ringtones, wallpapers, animations, games etc.

The request may include information query related to recent news, scientific facts, health guide, tourism, puzzles, horoscope, jokes etc. The request may also include request for uploading user generated content on the communication network. An example of such request would be uploading a file to be played as ring back tone when the user receives a call.

RSS 108 may be used for screening requests seeking information related to recent news, scientific facts, health guide, tourism, puzzles, horoscope, jokes etc. RSS 108 may also be used for screening the requests for uploading user generated content on the server provided by CSP. For example, RSS 108 maybe used to screen the multimedia files uploaded by the users on the CSP server. The multimedia files may contain performances provided by users during audition.

FIG. 3 illustrates RSS 108 connected to mobile device 104 for receiving a request in accordance with an embodiment of the invention. RSS 108 comprises local assemblage 302, central assemblage 304, and screening module (SM) 306. Local assemblage 302 is a geography specific request repository which collects all the incoming requests from a particular geographic area. User 102 may place a request to RSS 108 via communication network 106. The request first goes to local assemblage 302. Local assemblage 302 periodically forwards the request to central assemblage 304. Central assemblage 304 is a database which receives requests from all the local assemblages 302 connected to it. Central assemblage 304 is a repository of requests. The requests stored in central assemblage 304 have flag field and response field as the editable fields. The request stored in central assemblage 304 is accessed by screening module 306.

SM 306 comprises judging module 308, searching module 310, expert module 312 and notification module 314. Upon receiving a new request, central assemblage 304 triggers judging module 308 to view the new query.

In an embodiment of the invention, judging module 308 may be an automated system having an inbuilt dictionary. The inbuilt dictionary may contain a list of words provided by an administrator of RSS 108. The list of words in the inbuilt dictionary is referred to as "catch words'. The screening of the request is performed to check the presence of 'catch words' in the request. Presence of 'catch words' in a request may render the request objectionable. Based on the outcome of the screening, the request is tagged. In another embodiment of the invention, judging module 308 is an interface used by a judge to view and edit the flag field of the query. A judge would screen the requests and give a rating to the request. Based on the screening outcome, the flag field of the request is tagged by the judge with the rating. The tag may correspond to the quality of the request. For example, the good quality request may be tagged as 5 and the objectionable request may be tagged as 1 , on a scale of 1 to 5. The requests with tag 1 are objectionable and requests with any other tag are acceptable. When the request is acceptable, judging module 308 triggers searching module 310 and notification module 314. When the tag on the flag field corresponds to 'objectionable', judging module triggers only notification module 314. Notification module 314 notifies user 102 about the status of the request placed by user 102. In case the flag field is tagged 'objectionable', notification module 314 may send a response saying 'the request is screened', 'please request again', 'please do not place objectionable request'. When the request is acceptable, notification module 314 may send a response to user 102 saying 'please be patient while we process your request'.

When searching module 310 is triggered (in case of acceptable requests), it searches for a similar request having a previously filled response field. After finding a match, searching module 310 updates the response field of the request and triggers notification module 314 to send response to user 102. When a match for a similar request is not found in central assemblage 304, searching module 310 triggers expert module 312. Expert module 312 is an interface which allows one or more experts to view and edit response field of the request. The expert is a person qualified to answer such queries. The administrator of RSS 108 may interview aperson whit relevant experience to act as an expert in RSS 108. The expert may login periodically via expert module 312 and view recent queries. Expert module 312 maintains a log of requests answered by the expert and displays only the recent requests which have not been visited by the expert. When the expert updates the response field of a request in central assemblage 304, expert module 312 triggers notification module 314 to send the response to user 102.

FIG. 4 illustrates a method of screening a request in accordance with an embodiment of the invention. FIG. 4 is a flowchart depicting steps of the method of screening requests. User 102 may place a request using mobile device 104. The request may be a query related to a particular domain or a request to upload user generated content on the server provided by the CSP. The request may have flag field and response field associated with it. At step 402, local assemblage 302 of RSS 108 receives the request from user 102 via communication network 106. Local assemblage 302 may receive and store the request and forward the request to central assemblage 304 at a periodic interval of time. Upon receiving a new request, central assemblage 304 may trigger judging module 308 of SM 306 for screening the new request. At step 404, judging module 308 performs a screening of the request. Judging module 308 may be an automated system having an inbuilt dictionary based on which the request may be classified as 'acceptable' or 'objectionable'. The inbuilt dictionary may have catch words with appropriate tag. Based on the presence of the catch words in the request, it may be filtered. In an embodiment of the invention, the screening may be conducted manually by a judge. The judge may be a person having relevant qualification and authorization from RSS 108 administrator. The judge screens the request and updates the flag field of the request.

At step 406, based on the outcome of screening, SM 306 tags the request as 'acceptable' or 'objectionable' and central assemblage 304 triggers notification module 314 of SM 306 to send the outcome of screening to user 102. At step 408, SM 306 checks the tag on the request. The tag on the request may correspond to the quality of the request. In an embodiment of the invention, user 102 may be gratified by a reward depending on the tag.

Notification module 314 may send a response to user 102 saying 'the request is screened', 'request again', 'please do not place objectionable request' etc when the tag is 'objectionable'. Notification module 314 may send a response to user 102 saying 'please be patient while we process your request', when the tag on the request is 'acceptable'. Central assemblage 304 triggers searching module 310 when the flag field of the request is 'acceptable'. At step 410, searching module 310 searches for a response for requests tagged as the 'acceptable' in central assemblage 304.

Searching module 310 searches the response field of the requests stored in central assemblage 304. If the search retrieves a response satisfying the request, the response is forwarded to user 102. The process of searching response database 304 and sending the response to user 102 is automated using a search engine. The search engine may use key words present in the request to search for searching the response. The key words could be a set of words extracted form the request.

At step 412, SM 306 performs a check if response corresponding to the request is present in central assemblage 304. When response corresponding to a request is present in central assemblage 304, searching module 310 triggers notification module 314 to send the response to user 102. At step 414, when the response corresponding to the request is not present in central assemblage 304, searching module 310 triggers expert module 312. Expert module 312 is an interface which allows the expert to login and view the requests stored in central assemblage 304. Expert module 312 maintains a log of requests answered by the expert and displays only the recent requests which have not been visited by the expert. At step 416, SM 306 receives a response from the expert. The expert provides the response by updating the response field of a request in central assemblage 304 at step 418. The receiving of a response from the expert also triggers notification module 314 to send the response to user 102 at step 420. Similar future requests will now be served from central assemblage 304 as the response for such request is now present there.

In an embodiment in accordance with the invention, an auditioning system may use RSS 108 for screening the performance. The auditioning system provides a performance scenario to a participant. The participant may provide an audition file containing a performance to the CSP. RSS 108 may screen the audition file containing performance, uploaded by user 102 on the server provided by CSP for audition. The predefined criteria for screening may be checking if the audition file contains any offensive content or copyrighted content. RSS 108 receives an audition ■ file containing performance at step 402. At step 404, judging module 308 performs the check if the audition file received by RSS 108 is objectionable according to the predefined criteria. At step 406, SM 306 tags the audition as acceptable or objectionable. At step 408, SM 306 checks if the tag is acceptable. In an embodiment, when the tag is acceptable, SM 306 allows user 102 to upload the multimedia file. In another embodiment, when the tag is objectionable, SM informs user 102 about the result of the screening.

While example embodiments of the invention have been illustrated and described, it will be clear that the invention is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art without departing from the spirit and scope of the invention as described in the claims.

Claims

CLAIMS:

1. A method for managing a request in a communication network, the request being placed by a user of the communication network, the method comprising: a. receiving the request; b. screening the request based on one or more predefined conditions; c. tagging the request based on the screening; and d. processing the request based on the tag.

2. The method of claim 1 , wherein screening the request comprises: a. presenting the request to a judge; and b. receiving a judgment on the request from the judge, the judgment being based on the one or more predefined conditions.

^' 3. The method of claim 1 , wherein processing the request further comprises searching a response corresponding to the request in a database based on the tag.

4. The method of claim 3, the method further comprising sending the response to the user.

5. The method of claim 3, the method further comprising seeking the response from an expert when the response is not present in the database.

6. The method of claim 5, wherein seeking the response from an expert further comprises: a. presenting the request to an expert, the expert viewing the database at a pre-defined interval of time; b. receiving the response, the response being provided by the expert upon reading the request from the expert database; and c. updating the response in the response database.

7. The method of claim 6 further comprises sending the response to the user.

8. The method of claim 1 , wherein processing the request further comprises communicating the tag to the user.

9. A method for screening a request in a communication network, the request being placed by a user of the communication network, the method comprising: a. receiving the request; b. providing the request to a judge for screening, the screening being done to identify objectionable request; and c. tagging the request based on the screening.

10. A method for screening a request in a communication network, the request being placed by a user of the communication network, the method comprising: a. receiving the request; b. providing the request to a judging module for screening, the screening being done to identify objectionable request; and c. tagging the request based on the screening.

1 1. A system for managing a request in a communication network, the request being placed by a user of the communication network, the system comprising: a. a judging module for screening the request; b. a searching module for searching a response to the request in a database; c. an expert module for providing the response to the request; and d. a notification module for sending the response to the user.

12. A computer program product for managing a request in a communication network, the request being placed by a user of the communication network, the computer program product performing the steps of: a) receiving the request; b) screening the request based on one or more predefined conditions; c) tagging the request based on the screening; and d) processing the request based on the tag.