WO2007136314A1 - A method and arrangement for handling communication requests from unknown parties. - Google Patents
A method and arrangement for handling communication requests from unknown parties. Download PDFInfo
- Publication number
- WO2007136314A1 WO2007136314A1 PCT/SE2007/000443 SE2007000443W WO2007136314A1 WO 2007136314 A1 WO2007136314 A1 WO 2007136314A1 SE 2007000443 W SE2007000443 W SE 2007000443W WO 2007136314 A1 WO2007136314 A1 WO 2007136314A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- party
- contact list
- parties
- user
- calling
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/66—Substation equipment, e.g. for use by subscribers with means for preventing unauthorised or fraudulent calling
- H04M1/663—Preventing unauthorised calls to a telephone set
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/436—Arrangements for screening incoming calls, i.e. evaluating the characteristics of a call before deciding whether to answer it
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2203/00—Aspects of automatic or semi-automatic exchanges
- H04M2203/20—Aspects of automatic or semi-automatic exchanges related to features of supplementary services
- H04M2203/2044—Group features, e.g. closed user group
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/487—Arrangements for providing information services, e.g. recorded voice services or time announcements
- H04M3/493—Interactive information services, e.g. directory enquiries ; Arrangements therefor, e.g. interactive voice response [IVR] systems or voice portals
Definitions
- the present invention relates generally to a method and arrangement for handling an incoming call or other communication request from an unknown party.
- the invention can be used for determining how to respond to the incoming call or request.
- IP Internet Protocol
- IMS Multimedia Subsystem
- 3GPP 3 rd Generation Partnership Project
- IMS is a platform for enabling services based on IP transport, more or less independent of the access technology used and basically not restricted to any limited set of specific services.
- an IMS network can be connected to different access networks, such as mobile (or cellular) networks or broadband access networks, to enable multimedia sessions for terminals in communication with those access networks.
- an IMS network contains session managing nodes, subscriber databases and various application servers.
- the session managing nodes are used for controlling multimedia sessions, including the nodes S-CSCF (Serving Call Session Control Function) , I-CSCF (Interrogating Call Session Control Function) and P-CSCF (Proxy Call Session Control Function) .
- S-CSCF Server Call Session Control Function
- I-CSCF Interrogating Call Session Control Function
- P-CSCF Proxy Call Session Control Function
- Invoked multimedia services are enabled and executed by the application servers.
- a main database element HSS Home Subscriber Server
- HSS Home Subscriber Server
- SIP Session Initiation Protocol, according to the standard IETF RFC 3261 et al
- SIP Session Initiation Protocol, according to the standard IETF RFC 3261 et al
- SIP Session Initiation Protocol, according to the standard IETF RFC 3261 et al
- SIP Session Initiation Protocol, according to the standard IETF RFC 3261 et al
- IMS service networks is well-known in the field of telecommunication, and the various functions of the IMS network elements are not necessary to describe here further to understand the present invention.
- Presence services basically involve the publishing of "presence data" of a user to make it available for other users and applications, which further can be used to control other services ' in turn.
- Presence data basically defines the state or situation of- a user and his/her equipment in some predefined respect.
- Presence is ' here given a very broad meaning, and the presence data may include, by. way of example, the following:
- a user status e.g. available, busy, in a meeting, on holiday, etc.
- a terminal status e.g. switched on/off, engaged, out of coverage, etc.
- the geographic location of the user/terminal, as well as other aspects on the physical condition of the user/terminal may include: acceleration, orientation, light condition, temperature, etc.
- Terminal capabilities and selections including functions for SMS, MMS, chatting, games, video, etc.
- Other personal user information e.g. interests, occupations, personal characteristics, moods, etc.
- This information, or any selected parts thereof, is stored in an application server in the IMS network, based on so-called "publications of events" received from the network or a user, whenever the user changes any of his/her presence data.
- a user may also subscribe for selected presence data of one or more other users, e.g. according to a list of users.
- Such presence subscriptions are typically also handled by an application server in the IMS network.
- the subscribing user can then receive notifications regarding current presence data, either automatically or upon request.
- SIP a message called "SIP PUBLISH” can be used to provide dynamic data to an application server in the IMS network.
- another SIP message called "SIP SUBSCRIBE” can be used by users to subscribe for dynamic data of other users, as handled by the application server.
- the presence services are thus typically based on different communication groups of users that can be established around various subjects, such as a football team, a chat group, a working project, etc, and contact lists are maintained for such groups.
- the members When belonging to such a communication group, the members are naturally willing to communicate with other group members using certain specified functions and types of media.
- the set of available functions of a particular user are "exposed" to the group by means of the presence data and the above-mentioned publish/subscribe mechanisms.
- the mere fact that available functions and media types are exposed in this way for different users makes the users susceptible to illicit attacks or "spamming" over those functions and media types, e.g. after interception of messages communicated for the presence services. Further, users may have good reason to be cautious when being contacted by unknown parties since replying to a communication request or invitation will typically expose and even validate the current address of the called user to a potentially malicious caller.
- the exposed address may include an IP address, an e-mail address such as SIP-URI, an alias associated with an SIP-URI, etc.
- a calling party may send a. multimedia communication request or invitation with the intention of..sending or fetching content, e.g. a "file", in any format for texts, ⁇ images, video clips, audio, animations, etc.
- Any user of a communication terminal has typically created one or more contact lists in the terminal containing at least the name and contact number/address of known individuals such as friends, relatives and colleagues, hereafter referred to as "known parties".
- the known parties may naturally also include members of any communication • groups the user currently belongs to, e.g. using presence services according to the above.
- Contact lists for such communication groups are then maintained in corresponding application servers in a service network.
- search engines are also available over the Internet holding personal relationships, sometimes referred to as M friend-of- a-friend" data.
- each entry in a contact list is associated with different media that can be used for communication with that contact or party.
- the receiving terminal will typically notify the user automatically on the identity of the calling party on a terminal display or by means of a specific ring signal or the like. Thereby, the called user can decide how to respond depending on the identity of the calling party. In some cases, the terminal may itself decide how to respond automatically, e.g. based on the caller identity, any relevant contact lists defined for the called user including "black lists” or “white lists", respectively, or similar.
- This automatic response function is typically implemented as a user agent, or so-called "presence agent", either in the terminal or in an application server.
- the called user or user agent has basically three options: 1) respond with a message implying acceptance to communicate, 2) respond with a message implying rejection to communicate (which may be a so-called "polite block" message in the style of "out-of-office” or the like), and 3) not respond at all.
- FIG. 1 illustrates schematically a typical communication scenario where multiple contact lists have been defined for a user A 100, of which a first list 102 and a second list 104 are shown, for various purposes such as contact lists in the manner of a "phone book" or the like, or group lists for presence services, etc.
- the contact lists 102,104... may be stored in the user's communication terminal and/or in an application server e.g. handling corresponding presence services or the equivalent.
- the first shown list 102 includes users B, C, D...
- the term "user group” generally represents a se.t of users in. any contact list, presence group, etc., pre-defined for the called user. Of course, further user groups, contact lists or the like, not shown, may have been defined for user A. If a communication request R: 102 or R: 104 is received from any known user in group G: 102 or G: 104, respectively, the calling party identity and/or number/address will be known to user A and/or the receiving terminal accordingly, forming a basis for how to respond.
- the object of the present invention is to address at least some of the problems and issues outlined above.
- the inventive method and arrangement can be implemented in a communication network or terminal serving the called party.
- a relation query for the calling party is received from the called party, and the calling party is absent from any contact list that has been defined for the called party and comprising parties known and related to the called party. It is then determined whether the calling party is known and related to a third party directly or indirectly known and related to the called party, by checking if the third party is present in a contact list that has been defined for the third party and comprising parties known and related to the third party. Relation information is finally provided to the called party based on the outcome from said determination above.
- At least one directly known and related third party may be selected from a contact list that has been defined for the called party, and it is then checked whether the calling party is known and related to the selected directly known third party by being present in any contact list that has been defined for the selected directly known third party.
- the determination may further include selecting at least one indirectly known third party from a contact list that has been defined for a directly • . known and related third party, • and checking whether the calling party is known and related to the selected indirectly known third party by being present in any contact list that has been defined for the selected indirectly known ' third party.
- the inventive method and apparatus may be implemented in an application server in an IMS network, and the contact list defined for the called party may be a- group defined in said application server.
- the application server may be a presence server in the IMS network, and the contact list defined for the called party may then be a group defined for a presence service.
- the inventive method and apparatus may be implemented in an Internet server for providing ⁇ friend-of-a-friend" searches or the like.
- the directly or indirectly known third party may be selected from a contact list defined for a specific application being used.
- a response to the received relation query may also be sent to the called party, declaring either that the calling party is directly or indirectly known and related to one or more known third parties, or that the calling party is found to be wholly unrelated, depending on the outcome of the above determination.
- the response may be sent as soon as the calling party is found in a checked contact list.
- the above determination can be repeated for a plurality of third parties directly or indirectly known and related to the .called party, regardless of whether the calling party is found in a checked contact list or not, before sending the response.
- the response could be sent when a predetermined time-out period has . - elapsed, or when a predetermined number of checks have been executed. ..
- a logic policy engine can be created for deciding how to respond to incoming calls from unknown calling parties, based on any found relations of the calling- parties with directly and/or indirectly known and related third parties.
- a caller investigation unit is also defined for use in a service entity in a communication network or terminal serving a called party.
- the caller investigation unit comprises a query receiving part adapted to receive relation queries from called parties regarding unknown calling parties.
- the caller investigation unit further comprises a relation determining part adapted to determine whether an unknown calling party is indirectly related to a called party, by selecting one or more third parties from contact lists for either the called party or any third parties directly or indirectly known to the called party, and checking whether the unknown calling party is present in contact lists of the selected third parties.
- the caller investigation unit further comprises a response sending part adapted to send relation check responses to called parties in response to the relation queries, declaring either that a calling party is directly or indirectly known to .a known third party, or that a calling party is found to be wholly unrelated, depending on the. outcome from the relation, determining part.
- Fig. 1 is a schematic communication scenario when a user A receives calls from different known and unknown users, according to the prior art.
- - Fig. 2 is a schematic block diagram illustrating a procedure and arrangement when a user A receives a call from an unknown user X, according to one embodiment.
- Fig. 3 is a schematic block diagram illustrating a procedure and arrangement when a user A receives a call from an unknown user X, according to another embodiment.
- Fig. 4 is a flow chart illustrating a procedure for performing a caller investigation of an unknown calling party, according to another embodiment.
- Fig. 5 is a logic block diagram of a caller investigation unit, according to another embodiment.
- the present invention provides a solution for enabling assessment of whether an unknown calling party can be generally regarded as "reliable” or not in some respect. Basically, it is investigated whether the unknown caller is somehow indirectly related to the called party by being directly or indirectly related to any third party known to the called party, by checking a contact list defined for said third party.
- an incoming call from a calling party may be a voice call or a session invitation for other types of communication, including multimedia
- the term "communication request” will be used hereafter in a broad sense to generally represent any type of incoming call or session invitation.
- the terms "caller” and ⁇ 'calling party” should also be understood in a broad sense and will be used here to represent a person/terminal/server that sends any form of communication request according to the above.
- the calling party can be considered reliable if indirectly related and known in this way, such that the called party, i.e. a person or a user agent (either in the terminal or an application server) , can take any suitable action based upon that knowledge. It is thus assumed that an incoming call from a reliable party can be answered, accepted or otherwise responded to, without the risk of malicious attacks or the like.
- the calling party is directly or indirectly known to the third party, he/she may still be considered ⁇ unreliable", e.g. depending on a policy of the third party for handling contacts. For example, it may turn out that the calling party is indirectly known by being present on a black list or the like defined for the third party, implying that the calling party is considered unreliable or otherwise unsuitable for communication. If the caller is found not to be indirectly related to the called party in this way, and is thereby not considered reliable, the incoming call or session invitation can be treated accordingly, typically by not responding at all to eliminate any risk of malicious attacks. It should be noted that this solution provides a mechanism for investigating whether the unknown caller is somehow indirectly related to the called party or not, whereas the question of reliability is ultimately subject to assessment that can be based on the knowledge of any found relationship.
- FIG. 2 is a schematic block diagram illustrating an exemplary case when a user A denoted 200 receives a communication request from an unknown user X denoted 202.
- user A is the called party and user X is the calling party.
- a service entity 204 in a communication network serving user A is shown, which may be an IMS application server such as a presence server.
- Service entity 204 may also be an Internet server, e.g. for providing X ⁇ friend-of-a- friend" searches or the like.
- service entity 204 may also be implemented in a communication terminal used by user A.
- the service entity 204 may be any type of communication service entity or node serving user A, either within or outside a service network, or in the terminal of user A, and the present invention is not limited in this respect.
- a caller investigation unit 206 in service entity 204 is adapted to provide relation information on calling parties, according to the following description.
- a calling party or caller may be any person/terminal/server that sends any form of communication request to a called party.
- a contact list 208 of known users B, C, D, i.e. parties known and related to the called party, has-been- defined for user A, -which is stored in service entity 204.- Additionally, the contact .list- 208 may also be stored in a ⁇ terminal of user A and/or in a separate contact database in general.
- the present solution assumes that the list is. somehow available to caller investigation unit 206, either within the communication network and/or service entity serving user A, or from some external database or node.
- this solution can be used for so-called “buddy lists” or similar in connection with presence services provided in an IMS network.
- service entity 204 is a presence server where the contact list 208 is stored.
- user A refers primarily to a person, but it may also be a user agent acting automatically in the described manner when implemented either in a terminal or in an application server.
- user A 200 thus receives a communication request from user X 202, for commencing some kind of communication, e.g. a voice call or a multimedia session involving communication of media in either direction or both.
- User A detects that the calling party user X is unknown.
- user A sends a relation query for user X to the caller investigation unit 206, in a step 2:2, effectively asking whether the calling user X is indirectly related, to 1 user A in any way.
- the relation query may be. sent manually or automatically from user A.
- caller investigation unit 206 first checks contact list 208 in a following step 2:3 and finds that the calling party user X is not present there, and is thus not directly known and related to user A.
- contact list 208 may have been predefined for user A, but the present example is simplified in assuming only one such list.
- the following further steps can be executed.
- a user B being directly known and related to user A, is selected from user A' s contact list 208.
- a similar contact list 210 containing users E, F, G has also been defined for user B which is available to the caller investigation unit 206, in this case being stored in service entity 204.
- Caller investigation unit 206 then checks in a step 2:4 whether user X is present in user B' s contact list 210, to find out whether user X is thereby known and related to user B. In this example, user X is not found in B's contact list 210 either, and is thus not known to user B. •
- a similar contact list 212 containing users H, I, J has been likewise defined for user C, and caller investigation unit 206 checks in a further step 2:5 whether user X is present in user Cs contact list 212 to find out if user X is known and related to user C. Not found in contact list 212, user X is thus not known to user C either.
- caller investigation unit 206 checks in a further step 2:6 whether user X is known and related to user D by being present in a contact list 214 predefined for user D and containing users K x L f X known and related to user D.
- user X is actually found 'in user D's contact list 214, implying that user X is indirectly known and related to user A by being directly known .and related to user D.
- user D is thus a third party directly, known and related to the called user A since present in contact list 208.
- caller investigation unit 206 communicates a relation check response to user A in a step 2:7, in response to the relation query of step 2:2, basically declaring that "X is known to D who is known to A", or anything similar to that effect. Hence, user A is now free to consider this fact when deciding how to respond to the communication request from user X, received initially in step 2:1.
- a service entity 304 implemented as a node in a communication network serving user A or in a communication terminal used by user A, comprises a caller investigation unit 306 adapted to provide relation information on calling parties.
- a first step 3:1 user A receives a request for communication from user X who is unknown to user A, and user A therefore sends a relation query for user X to the caller investigation unit 306, in a step 3:2.
- caller investigation unit 306 retrieves contact list 308 in a following step 3:3, where user X cannot be found, and selects a known user B therefrom.
- a contact list 310 containing users E, F, G known and related to user B has been defined for user B, in this case likewise stored in service entity 304.
- Caller investigation unit 306 then checks in a step 3:4 whether user X is present in B' s contact list 310, but finds that he/she is not.
- a similar check may be performed for other users C and D selected from user A' s contact list 308, by checking the presence of user X in their contact lists 312 and 314, respectively, as illustrated by an optional further step 3:4a.
- the process moves on one level further by selecting a user E from the contact list 310 for user B and checking a contact list 316 predefined for the selected user E. That is, the selected user E is directly known and related to user B and thereby indirectly known and related to user A via user B.
- Caller investigation unit 306 checks in a further step 3:5 whether user X is present in the selected user E' s contact list 316, to find out if user X is known and related to user E.
- contact list 316 contains users H, I, X and user X is accordingly found there, thus being known and related to user E. Consequently, user X is indirectly known and related to user A by being directly known and related to user E and indirectly known and related to user B via user E.
- user E is thus a third party indirectly known and related to the called user A since present in contact list 310 of user B who in turn is present in the contact list 308 of user A.
- the checking process might have continued for other users F and G selected from user B's contact list 310 in their respective contact lists 318 and 320, as illustrated by an optional further step 3:5a. Indeed, such further checks may also be performed for any number of users in any of contact lists 310, 312 and 314 for B, C and D, respectively, regardless of whether user X is found or not. It may then turn out that user X is known and related to more than one other user, which would reasonably increase the reliability of user X, or at least provide a better basis for the decision of how to respond.
- the caller investigation unit 306 communicates a relation check response to user A in a step 3:6, in response to the relation query of step 3:2, declaring that "X is known to E who is known to B who is known to A", or similar.
- user A can consider this fact when deciding how to respond to the communication request from user X, received initially in step 3:1. Any additional other users found knowing user X may be included in this message as well.
- a logic policy engine may be created for user A for how to consider any found relations of user X with directly or indirectly known other users or third parties.
- Such a policy engine may be adapted to aggregate similar policy engines of other users directly and indirectly known to user A, in order to automatically filter and/or otherwise handle incoming calls accordingly from unknown callers.
- the relation check of how the calling. user X is related to the called user A is made in one level by checking the contact lists of users present in the contact list for the called user A.
- this relation check is taken one level further by also checking the contact lists of users present in the contact lists of users present in user A' s contact list.
- there is no limit in the present solution as to how many user' s contact lists and/or levels that can be checked in the above-described manner.
- This procedure may be executed in a service entity in a communication network or terminal serving a called party, and more specifically in a caller investigation unit such as in the examples of Fig' s 2 and 3, respectively.
- a relation guery is received from a called party, as to whether an unknown calling party is indirectly related to the called party in any way, basically corresponding to steps 2:2 and 3:2, respectively, in the above examples.
- the calling party is thus absent from any contact list or presence group that has been predefined for the called party, hence unknown.
- a directly known and related third party is selected from a contact list of the called party.
- the third party may be selected from a contact list defined for a specific application being used, such as IM.
- a contact list of the selected third party is checked with respect to the calling party, in a step 404.
- step 410 If the calling party is determined as not being present in the checked contact list in step 406, it is determined in a further step 410 whether there are any further third party that can be subject to a contact list check as in step 404. If so, the process returns to step 402 and another third party is selected in order to check whether the calling party is present in his/her contact list. When there are no more third party to check, or a predetermined time-out period has elapsed, or a predetermined number of checks have been executed, a relation check response is sent to the called user effectively declaring that the calling party is found to be wholly unrelated, in a final step 412.
- the above-described process of Fig. 4 can be modified in different ways.
- steps 402, 404 and 410 may be repeated for any number of third parties directly or indirectly known to the called party, regardless of whether the calling party is found in a contact list or not, thus omitting the determining step 406.
- Certain third parties known to the called party who may be particularly trustworthy may have been preselected by the called party for checking their contact lists in the first place. Then, after exhausting any relevant . contact lists, the relation check response of either step 408 or 412 may be sent to the called party, depending on the outcome of the executed caller investigation.
- the checking process may continue until a predetermined time-out period has elapsed, or a predetermined number of checks have been executed. At this point, the relation check response can be finally issued, regardless of whether the calling party is found or not.
- the caller investigation unit 500 comprises a query receiving part 502, a relation determining part 504 and a response sending part 506.
- the query receiving part 502 is basically adapted to receive relation queries Q from called parties regarding unknown calling parties, e.g. as described for steps 2:2 and 3:2 in Fig's 2 and 3, respectively.
- the relation determining part 504 is basically adapted to find out whether an unknown calling party is somehow indirectly related to a called party, by selecting third parties from contact lists L for either the called party or any third parties directly or indirectly known to the called party, and checking whether the unknown calling party is present in contact lists of the selected third parties, e.g. as described for steps 2:3-2:6 and 3:3-3:5a in Fig's 2 and 3, respectively.
- the response sending part 506 is basically adapted to send relation check responses R to called parties in response to the relation queries Q, declaring either that a calling party is directly or indirectly known to a known third party, or that a calling party is found to be wholly unrelated, depending on the outcome from the relation determining part 504, e.g. as described for steps 2:7 and 3:6 in Fig's 2 and 3, respectively.
- the present invention thus provides a solution for investigating whether an unknown calling party is somehow indirectly related to a called party by being directly or indirectly related to any third party known and related to the called party.
- the called party may be able to better assess whether the unknown calling party can be regarded as "reliable" or not in some respect, which can be used for deciding how to handle the incoming call, either manually by a person or automatically by a user agent.
- an aggregated network of trusted relationships is basically formed by effectively linking the contact lists of directly or indirectly known and related parties in the above-described manner. This information of such linked relationships would otherwise be practically impossible to build up and maintain as a single database for a specific user.
- a logic policy engine may be created for a user for deciding how to respond to incoming calls from unknown callers, considering any found relations of a calling party with directly or indirectly known other users or third parties.
- the logic policy engine may be dictated by the user's assessments -of various calling parties or third parties, where some parties are deemed more trustworthy or reliable than others.
- a logic policy engine may be configured to accept communication requests and/or add a calling party to a group for a called party, if found related in a trustworthy manner. Even third parties indirectly known and related to the called party may be included in the group.
- a group learning mechanism may also be used for forming a policy for such a group.
- some users may allow or not allow certain other users to look up their contact lists and policies, which must also be taken into account.
- the logic policy engine may also be configured to ⁇ aggregate similar policies of other users, and to apply various algorithms, either by default or selectively, for assessing whether an unknown party can be deemed reliable or not. For example, one algorithm may dictate that an unknown calling party will be deemed unreliable if he/she is present on a contact list of anyone previously deemed unreliable, and so forth.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA002652366A CA2652366A1 (en) | 2006-05-19 | 2007-05-07 | A method and arrangement for handling communication requests from unknown parties |
GB0822907A GB2452206A (en) | 2006-05-19 | 2007-05-07 | A method and arrangement for handling communication requests from unknown parties |
US12/301,583 US8345843B2 (en) | 2006-05-19 | 2007-05-07 | Method and arrangement for handling communication requests from unknown parties |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
SE0601124 | 2006-05-19 | ||
SE0601124-1 | 2006-05-19 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2007136314A1 true WO2007136314A1 (en) | 2007-11-29 |
Family
ID=38723553
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/SE2007/000443 WO2007136314A1 (en) | 2006-05-19 | 2007-05-07 | A method and arrangement for handling communication requests from unknown parties. |
Country Status (4)
Country | Link |
---|---|
US (1) | US8345843B2 (en) |
CA (1) | CA2652366A1 (en) |
GB (1) | GB2452206A (en) |
WO (1) | WO2007136314A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2091217A1 (en) * | 2008-02-18 | 2009-08-19 | Research In Motion Limited | Message filter program for a communication device |
WO2010034345A1 (en) * | 2008-09-24 | 2010-04-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Method of controlling operation of telecommunications network |
US8229413B2 (en) | 2008-02-18 | 2012-07-24 | Research In Motion Limited | Message filter program for a communication device |
Families Citing this family (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8370769B2 (en) * | 2005-06-10 | 2013-02-05 | T-Mobile Usa, Inc. | Variable path management of user contacts |
US7685530B2 (en) | 2005-06-10 | 2010-03-23 | T-Mobile Usa, Inc. | Preferred contact group centric interface |
US8370770B2 (en) * | 2005-06-10 | 2013-02-05 | T-Mobile Usa, Inc. | Variable path management of user contacts |
US8359548B2 (en) * | 2005-06-10 | 2013-01-22 | T-Mobile Usa, Inc. | Managing subset of user contacts |
US20100310952A1 (en) * | 2006-05-10 | 2010-12-09 | Sincono Ag | Oil-bearing sands and shales and their mixtures as starting substances for producing silicon nitride and/or silicon carbide |
US8255281B2 (en) * | 2006-06-07 | 2012-08-28 | T-Mobile Usa, Inc. | Service management system that enables subscriber-driven changes to service plans |
USD631891S1 (en) | 2009-03-27 | 2011-02-01 | T-Mobile Usa, Inc. | Portion of a display screen with a user interface |
US8577350B2 (en) | 2009-03-27 | 2013-11-05 | T-Mobile Usa, Inc. | Managing communications utilizing communication categories |
US9369542B2 (en) * | 2009-03-27 | 2016-06-14 | T-Mobile Usa, Inc. | Network-based processing of data requests for contact information |
US9210247B2 (en) | 2009-03-27 | 2015-12-08 | T-Mobile Usa, Inc. | Managing contact groups from subset of user contacts |
USD636399S1 (en) | 2009-03-27 | 2011-04-19 | T-Mobile Usa, Inc. | Portion of a display screen with a user interface |
US9355382B2 (en) | 2009-03-27 | 2016-05-31 | T-Mobile Usa, Inc. | Group based information displays |
USD631886S1 (en) | 2009-03-27 | 2011-02-01 | T-Mobile Usa, Inc. | Portion of a display screen with a user interface |
USD636403S1 (en) | 2009-03-27 | 2011-04-19 | T-Mobile Usa, Inc. | Portion of a display screen with a user interface |
USD631889S1 (en) | 2009-03-27 | 2011-02-01 | T-Mobile Usa, Inc. | Portion of a display screen with a user interface |
US8893025B2 (en) * | 2009-03-27 | 2014-11-18 | T-Mobile Usa, Inc. | Generating group based information displays via template information |
USD631887S1 (en) | 2009-03-27 | 2011-02-01 | T-Mobile Usa, Inc. | Portion of a display screen with a user interface |
USD636401S1 (en) | 2009-03-27 | 2011-04-19 | T-Mobile Usa, Inc. | Portion of a display screen with a user interface |
USD631888S1 (en) | 2009-03-27 | 2011-02-01 | T-Mobile Usa, Inc. | Portion of a display screen with a user interface |
USD633918S1 (en) | 2009-03-27 | 2011-03-08 | T-Mobile Usa, Inc. | Portion of a display screen with a user interface |
US9195966B2 (en) | 2009-03-27 | 2015-11-24 | T-Mobile Usa, Inc. | Managing contact groups from subset of user contacts |
USD636400S1 (en) | 2009-03-27 | 2011-04-19 | T-Mobile Usa, Inc. | Portion of a display screen with a user interface |
USD631890S1 (en) | 2009-03-27 | 2011-02-01 | T-Mobile Usa, Inc. | Portion of a display screen with a user interface |
JP5664103B2 (en) * | 2010-10-08 | 2015-02-04 | ソニー株式会社 | Information processing apparatus, information processing method, and program |
US20120159580A1 (en) * | 2010-11-24 | 2012-06-21 | Galwas Paul Anthony | Method of Establishing Trusted Contacts With Access Rights In a Secure Communication System |
GB2524302A (en) * | 2014-03-20 | 2015-09-23 | Ibm | Verifying telephone caller origin |
US10659606B2 (en) * | 2018-10-08 | 2020-05-19 | International Business Machines Corporation | Filtering unsolicited incoming calls |
CN110351101B (en) * | 2019-07-31 | 2021-08-27 | 维沃移动通信有限公司 | Group invitation processing method, system and mobile terminal |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1999057916A1 (en) * | 1998-05-05 | 1999-11-11 | Nokia Networks Oy | Handling of forwarded calls |
EP1143667A2 (en) * | 2000-04-06 | 2001-10-10 | Nokia Corporation | Method and system for accessing wirelessly a network phonebook and a journal database |
EP1396989A2 (en) * | 2002-09-04 | 2004-03-10 | Nec Corporation | Communication terminal device, telephone unit, system and method to notify caller information, as well as the corresponding programm and storage medium |
US20060046720A1 (en) * | 2004-09-02 | 2006-03-02 | Teemu Toropainen | Mobile communications terminal, system and method therefore |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6934862B2 (en) * | 2000-01-07 | 2005-08-23 | Robertshaw Controls Company | Appliance retrofit monitoring device with a memory storing an electronic signature |
US20030130893A1 (en) * | 2000-08-11 | 2003-07-10 | Telanon, Inc. | Systems, methods, and computer program products for privacy protection |
US7263085B2 (en) * | 2003-12-29 | 2007-08-28 | Motorola, Inc. | Apparatus and method for controlling connection status |
US7797293B2 (en) * | 2004-06-24 | 2010-09-14 | Oracle America, Inc. | Adaptive contact list |
US7536710B2 (en) * | 2005-01-28 | 2009-05-19 | Microsoft Corporation | Application-backed groups in a common address book |
KR100700586B1 (en) * | 2005-07-20 | 2007-03-28 | 엘지전자 주식회사 | Apparatus and method for controlling message of mobile terminal |
US8009812B2 (en) * | 2006-10-31 | 2011-08-30 | At&T Intellectual Property I, L.P. | System and method of audible caller identification via a multimedia device |
US20080125148A1 (en) * | 2006-11-27 | 2008-05-29 | Motorola, Inc. | Conveying relation information using electronic business cards |
-
2007
- 2007-05-07 US US12/301,583 patent/US8345843B2/en active Active
- 2007-05-07 GB GB0822907A patent/GB2452206A/en not_active Withdrawn
- 2007-05-07 WO PCT/SE2007/000443 patent/WO2007136314A1/en active Application Filing
- 2007-05-07 CA CA002652366A patent/CA2652366A1/en not_active Abandoned
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1999057916A1 (en) * | 1998-05-05 | 1999-11-11 | Nokia Networks Oy | Handling of forwarded calls |
EP1143667A2 (en) * | 2000-04-06 | 2001-10-10 | Nokia Corporation | Method and system for accessing wirelessly a network phonebook and a journal database |
EP1396989A2 (en) * | 2002-09-04 | 2004-03-10 | Nec Corporation | Communication terminal device, telephone unit, system and method to notify caller information, as well as the corresponding programm and storage medium |
US20060046720A1 (en) * | 2004-09-02 | 2006-03-02 | Teemu Toropainen | Mobile communications terminal, system and method therefore |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2091217A1 (en) * | 2008-02-18 | 2009-08-19 | Research In Motion Limited | Message filter program for a communication device |
US8229413B2 (en) | 2008-02-18 | 2012-07-24 | Research In Motion Limited | Message filter program for a communication device |
US8805426B2 (en) | 2008-02-18 | 2014-08-12 | Blackberry Limited | Message filter program for a communication device |
WO2010034345A1 (en) * | 2008-09-24 | 2010-04-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Method of controlling operation of telecommunications network |
US9032018B2 (en) | 2008-09-24 | 2015-05-12 | Telefonaktiebolaget L M Ericsson (Publ) | Provisioning of content items in mobile communications networks |
Also Published As
Publication number | Publication date |
---|---|
GB0822907D0 (en) | 2009-01-21 |
US20100020953A1 (en) | 2010-01-28 |
GB2452206A (en) | 2009-02-25 |
CA2652366A1 (en) | 2007-11-29 |
US8345843B2 (en) | 2013-01-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8345843B2 (en) | Method and arrangement for handling communication requests from unknown parties | |
US8041344B1 (en) | Cooling off period prior to sending dependent on user's state | |
US8509406B2 (en) | Presence enhanced telephony service architecture | |
US11095664B2 (en) | Detection of spoofed call information | |
US8799484B2 (en) | Methods and systems for facilitating transfer of sessions between user devices | |
US9225829B2 (en) | Method and system for providing communication party related information | |
CA2654538C (en) | Methods and systems for facilitating transfer of sessions between user devices | |
US9031067B2 (en) | Routing messages | |
US9363298B2 (en) | Methods and systems for aggregating presence information to provide a simplified unified presence | |
US7991895B2 (en) | Limiting access to network functions based on personal characteristics of the user | |
US8429260B2 (en) | Methods and apparatus for user persona management | |
US7412522B2 (en) | System and method for facilitating communication using presence and communication services | |
US8375426B2 (en) | Method and arrangement for handling client data | |
US20090067408A1 (en) | Centralized call log and method thereof | |
US20060030264A1 (en) | System and method for harmonizing changes in user activities, device capabilities and presence information | |
US20050071428A1 (en) | Method and apparatus for delivering an electronic mail message with an indication of the presence of the sender | |
US20040246965A1 (en) | System and method for routing messages | |
EP2166733B1 (en) | Methods and systems for aggregating presence information to provide a simplified unified presence | |
AU2004214336A1 (en) | Routing messages via an IMS system | |
US20080037574A1 (en) | Method for securing privacy in automatic answer mode of push-to service | |
US20090049087A1 (en) | Methods, systems, and computer program products for providing a universal uniform resource identifier (UURI) | |
RU2368100C2 (en) | Services presentation in communication system | |
Nyarko et al. | Ensuring Privacy in Presence Awareness Systems: Next Generation Networks | |
Kaloxylos et al. | Extending sip to enable a more efficient multimedia session control in future networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 07748107 Country of ref document: EP Kind code of ref document: A1 |
|
DPE1 | Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101) | ||
WWE | Wipo information: entry into national phase |
Ref document number: 8795/DELNP/2008 Country of ref document: IN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2652366 Country of ref document: CA |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 0822907 Country of ref document: GB Kind code of ref document: A Free format text: PCT FILING DATE = 20070507 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 0822907.2 Country of ref document: GB |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 07748107 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 12301583 Country of ref document: US |