Title of Invention

METHOD AND SYSTEM FOR PRESENCE BASED PRESENCE NOTIFICATION FILTERING

Abstract

The invention relates to the field of Session Initiation Protocol (SIP) technologies. In particular, the invention proposes a method for optimizing presence notification of one or more users to reduce network traffic.A watcher sends a request to subscribe to a resource list server (RLS) to get information of presentity of one or more users. The request includes filtering rules for presence notification of the one or more users based on the presence status of the watcher. For example, the watcher may set a rule to block all presence notification when its status is set to 'Busy'. Accordingly, based on the notification filtering rules and presence of the watcher, the RLS sends notification to the watcher regarding the presence status (or change therein) of the one or more users.

Full Text

FIELD OF THE INVENTION The invention relates to the field of Session Initiation Protocol (SIP) technologies. In particular, the invention proposes a method for optimizing presence notification of one or more users to reduce network traffic. More particularly the present invention relates to a system and method for presence based presence notification filtering for resource list in resource list server and for multiple subscriptions in presence server. DESCRIPTION OF THE RELATED PRIOR ART The presence system architecture helps to share the presence information of any user to others. The presence information basically is the information related to user like current location of user, available contact information for user, application specific information like Instant message related, User is online in IM client or offline, POC specific attributes etc. Currently user needs to subscribe to the presence information of the required user, and then other user authorizes the user for seeing his presence information. The Presence Server entity maintains the presence subscription and stores the presence information of users. As soon as presence information of user changes. Presence Server sends the notification to the Watchers. The Watchers are basically users who are authorized to watch presence attributes of a user. Currently once user subscribes to presence information he will continuously receives the notification of presence information change. The SIP SUBSCIBE and SIP NOTIFY methods are used for the subscribing and notifying. There is huge notifications and publications traffic which is the primary concern for the network operators. As number of user increases load will be further increasing. As per current state of art, there are cases where unnecessary notification traffic flows through network entity and access network. The current state of art supports the definition of filters for the presence information in a notification body. The notification body consists of various presence information of Presentity. There are number of presence attributes for a user, so Watcher may not be interested in all presence attributes. This is achieved by defining the filters in SUBSCRIBE body. User will define the filter rules in the subscription body which filter help in subscribing the required presence attributes. This filter rules are defined in the IETF draft "Functional Description of Event Notification Filtering draft-ietf-simple-event-filter-funct-05". This filtering rule also defines the rules for when to send the notification, by setting the particular condition for some presence attributes for e.g. status for Available presence attributes changes from Offline to Online then send the notification. These kind of filtering rules can be assigned in the body of subscribe request, so this filtering rules are use to set the content level. Current specification also allows Watcher to create a resource list in the Resource List Server (RLS) which allows watcher to subscribe to multiple presentities with single subscription. RLS will subscribe to various presentities on behalf of Watcher and send the combined notifications. Figure 1 shows basic architecture for handling of subscription of resource list presence information. The function entity called Resource List Server will handle these subscriptions. If Watcher wants to subscribe to multiple Presentity using single subscribe then Watcher creates a group associated with presentities and stores it into RLS XDMS server. The Watcher can use group identity created earlier for subscribing to presence information of presentities. As shown in the Figure 1, Watcher W sends a SUBSCRIBE request with group identity in Request-URI to RLS and then RLS creates individual subscriptions with Presence Server of Presentities (PS of Presentity A, PS of Presentity B, and PS of Presentity 0). RLS also aggregates the notifications coming from the PS of Presentities and send to the Watcher W, The patent application 1442/CHE/2006 title SYSTEM AND METHOD FOR PRESENCE BASED PRESENCE NOTIFICATION FOR OPTIMIZATION OF PRESENCE NOTIFICATION, discuss the system and method for setting the notification blocking filter rules based on Watcher's presence. This invention proposes the system and method for handling of notification blocking filter rules for individual subscriptions maintained in the Presence Sen/er, where the Presence Server blocks the notifications to Watcher when the current presence attributes of the Watcher matches the notification blocking filter rule as specified in the subscnption. This invention proposes to use the SUBSCRIBE method to carry notification blocking filter rules. This invention also describes example schemas for notification blocking filter rules LIMITATIONS Current filter mechanism defined by IETF draft-ietf-simple-event-filter-funct-05 allows Watcher to set content level filtering rules for subscribing only to the part of presence information of the Watcher's interest. This will help Watcher to receive only those part of presence information instead of the whole presence information, and thus will help in decreasing the amount of traffic in the network. The invention 1442/CHE/2006 proposes to further decrease the amount of presence information traffic in the network by allowing Watcher to set the Watcher's presence based notification blocking filter rule which directs Presence Server to suppress the delivery or notifications of presence information to Watcher when the Watcher does not wish to receive it. This invention as mentioned in the previous section covers setting of notification blocking filter rules in the Presence Server for subscriptions maintained in the Presence Server. As discussed in the previous RLS allows Watcher to create a resource list for multiple Presently so that Watcher can subscribe to multiple presentities using single subscribe request. However, the invention 1442/CHE/2006 does not cover this RLS based scenario for setting and handling of notification blocking filter rules based on Watcher's presence information for resource list. Further, as per the invention 1442/CHE/2006, Watcher needs to send the individual subscriptions to Presence Server to set the notification blocking filter rules in the Presence Server for existing subscription for presence information. In other words. Watcher's presence based notification control can be made only per Presentity base. So, when there's multiple Presentity, the Watcher should issue separate requests for each Presentity, even when the actual notification control is same. This invention proposes to solve above two weaknesses. This invention proposes system and method for setting notification blocking filter rules for resource list in RLS, This invention also proposes to solve problems of sending multiple subscribe request to Presence Server for setting same filtering rules for all subscription. This invention propose to have single request for setting notification blocking filter rules for all subscriptions existing in the Presence Server. SUMMARY OF THE INVENTION This innovation deals with system and method for optimizing the presence notifications. This innovation aims to avoid the unnecessary notifications thereby reducing the network load and annoying notifications for users. The invention 1442/CHE/2006 "Watcher presence based notification control' provides system and method for setting the Watcher's presence based filtering rules for notification of presence information. This innovation extends invention 1442/CHE/2006 "Watcher presence based notification control" with the system and methods to set the Watcher's presence based notification blocking filter in case of RLS presence subscription. Further, this invention also provides the system and methods for setting Watcher's presence based notification blocking filtering rules for all presence subscriptions existing in Presence Server using single request. Accordingly the invention explains a method of presence notification filtering comprising the steps of: sending SUBSCRIBE method by a watcher and including the notification blocking filter rules based on Watcher's Presence information; subscribing to individual presentities as per Watcher request by RLS; subscribing to Presence information of Watcher by RLS; and applying notification blocking filter rules on notifications of presence information of Presentities to the Watcher by RLS, once RLS gets notification about the presence information of Watcher. Accordingly the invention explains a method of presence notification filtering comprising the steps of: sending REFER method by a watcher and including the notification blocking filter rules based on Watcher's Presence information; subscribing to Watcher presence information by RLS in order to apply notification blocking filter rules; subscribing to Presence information of Watcher by RLS; applying notification blocking filter rules by RLS on notifications of presence information from all Presentities in the resource-list, once RLS gets notification about the presence information of Watcher. Accordingly the invention explains a method of presence notification filtering comprising the steps of: Using a SUBSCRIBE method as notification blocking filter rules; Using a Request-URI header field to differentiate this SUBSCRIBE and norma) subscribe; and indicating the applicability of the filtering rules indicated in the SUBSCRIPTION to all subscriptions maintained by a Presence Sen/er for corresponding Watcher by the Request-URI header. wherin allowing Watcher to use single request to set notification blocking filter rules to all subscriptions. Accordingly the invention explains a method of presence notification filtering comprising the steps of: using the REFER method as Watcher's presence based notification blocking filter rules; setting a Request-URI field to Presence Server URI, and "Refer-to" "header field set to a Watcher's URI with the referred operation to be the subscriptions to the 'presence' event package to the Watcher's presence information; providing the REFER request with the notification blocking filter rules; subscribing to the presence information of the Watcher and applying the requested notification blocking filter rules to all kinds of presence notifications towards the Watcher by a Presence Server, upon receiving this REFER request, Wherein allowing Watcher to use single request to set notification blocking filter rules to all presence subscriptions that the Watcher maintains. Accordingly the invention explains a method of presence notification filtering comprising the steps of: providing an Event Package for storing the notification blocking filter rules based on Watcher's presence information; PUBLISH the notification blocking filter rules by Watcher if Watcher wants to set the notification blocking filter rules; and maintaining the rules and applying these rules by the Presence Server as per Watcher request. Accordingly the invention explains a method of presence notification filtering comprising the steps of: sending the PUBLISH to publish the state and mentioning the indicator on whether to block all notifications by a Watcher; including a blocking parameter in a Event header w/hen Watcher wants to block the notification Watcher; and blocking all notification corresponding to that Watcher by the Presence Server whenever receives the PUBLISH with this optional parameter in Event header. Accordingly the invention explains a method of presence notification filtering comprising the steps of: sending the PUBLISH to publish state and including the Presence attribute state and including the notification filters by a Watcher; PUBLISH having multipart as content type, one part used to specify the presence attribute and other part include the notification blocking filter rules and blocking all notification corresponding to the condition mentioned in the PUBLISH method by the Presence Server whenever receives the PUBLISH with the optional body for notification blocking filter rules. Accordingly the invention explains a system for presence notification filtering comprising: watcher sending SUBSCRIBE method and including the notification blocking filter rules based on Watcher's Presence information; RLS subscribing to individual presentities as per Watcher request by RLS and subscribing to Presence information of Watcher; and Wherein RLS apply notification blocking filter rules on notifications of presence information of Presentities to the Watcher, once RLS gets notification about the presence information of Watcher. Accordingly the invention explains a system for presence notification filtering comphsing: a watcher sending REFER method and including the notification blocking filter rules based on Watcher's Presence information; RLS subscribing to Watcher presence informafion in order to apply notification blocking filter rules and subscribing to Presence information of Watcher; Wherein RLS apply notification blocking filter rules on notifications of presence information from all Presentities in the resource-list, once RLS gets notification about the presence informafion of Watcher. Accordingly the invention explains a system for presence notification filtering comprising: a Watcher Using a SUBSCRIBE method as notification blocking filter rules; a Request-URI header field to differentiate this SUBSCRIBE and normal subscribe and the Request-URI header indicating the applicability of the filtering rules indicated in the SUBSCRIPTION to all subschptions maintained by a Presence Server for corresponding Watcher, wherein allowing Watcher to use single request to set notification blocking filter rules to all subscriptions. Accordingly the invention explains a system for presence notification filtering comprising: a Watcher using the REFER method as Watcher's presence based notification blocking filter rules; a Request-URI field set to Presence Server URI, and "Refer-to" header field set to a Watcher's URI with the referred operation to be the subscriptions to the 'presence' event package to the Watcher's presence information; REFER request provided with the notification blocking filter rules; and a Presence server subscribing to the presence information of the Watcher and applying the requested notification blocking filter rules to all kinds of presence notifications towards the Watcher, upon receiving this REFER request, Wherein allowing Watcher to use single request to set notification blocking filter rules to all presence subscriptions that the Watcher maintains. Accordingly the invention explains a system for presence notification filtering comprising: an Event Package provided for storing the notification blocking filter rules based on Watcher's presence information; a Watcher PUBLISH the notification blocking filter rules if Watcher wants to set the notification blocking filter rules ; and a Presence Server maintaining the rules and applying these rules as per Watcher request. Accordingly the invention explains a system for presence notification filtering comprising: a Watcher sending the PUBLISH to publish the state and mentioning the indicator on whether to block all notifications; a Event header including a blocking parameter when Watcher wants to block the notification Watcher; and a Presence Server blocking all notification corresponding to that Watcher whenever receiving the PUBLISH with this optional parameter in Event header. Accordingly the invention explains a system for presence notification filtering comprising: a Watcher sending the PUBLISH to publish state and including the Presence attribute state and including the nofification filters; PUBLISH having multipart as content type, one part used to specify Hie presence attribute and other part include the notification blocking filter rules and a Presence Server blocking all nofification corresponding to the condition menfioned in the PUBLISH method whenever receiving the PUBLISH with the optional body for notification blocking filter rules. These and other objects, features and advantages of the present invenfion will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE ACCOMPANYING FIGURES Figure 1 illustrates the RLS Basic architecture Figure 2 illustrates the Basic proposal for setting notification rules in RLS architecture Figure 3 illustrates the Detailed flow diagram for resource list case using SUBSCRIBE method Figure 4 illustrates the Basic proposal for setting notification rules using REFER method. Figure 5 illustrates the Detailed flow diagram for resource list case using REFER method. Figure 6 illustrates the Detailed flow diagram for setting filtering rules for all subscription using SUBSCRIBE method Figure 7 illustrates the Detailed flow diagram for setting filtering rules for all subscription using REFER method Figure 8 illustrates the Detailed flow diagram for setting filtering rules for all subscription using PUBLISH method. DETAILED DESCRIPTION The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be emooaiea in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described In order not to unnecessarily obscure the present invention in detail. Current presence system allows user to subscribe to presence information of other users. The Presence Server maintains the subscription information and presence information. Current presence system defined in OMA Presence and Availability Group allows user to define the filter for controlling the amount of information sent in notification. Currently notification rate also can be control by time attribute. Still there are number of occasion where unwanted notifications generated by presence server, which might cause unnecessary heavy load on the network traffic. This innovation aims to ease this problem by further controlling the notifications to Watchers. The invention 1442/CHE/2006 "Watcher presence based notification control" proposes system and method for setting notification blocking filter rules based on Watcher's presence information for each Presentity. As per invention 1442/CHE/2006 "Watcher presence based notification control" notification blocking filter rules are sent along with the SUBSCRIBE request for presence information. Watcher can include this Water's presence based notification blocking filter rules in the initial subscribe request or can issue re-subscribe request for setting Water's presence based notification blocking filter rules. This invention also gives Water's presence based notification filter body format for setting notification blocking filter rules based on Watcher's presence. The Presence Server when receives SUBSCRIBE request with Water's presence based notification blocking filter rules. Presence Server suppresses the notifications to Watchers when the Watcher's presence matches the conditions specified in this rules. This saves unwanted notifications and hence saves the network resources. This invention extends the invention 1442/CHE/2006 "Watcher presence based notification control" by supporting the setting of notification blocking filter njles for RLS presence subscriptions. Further, this invention also proposes to have single request for setting the notification filleting rules for all subscriptions exisfing in the Presence Server. These methods are discussed next. This invention proposes to include the watcher's presence based notification filtering rules in SUBSCRIBE request this subscribe can be handle by RLS or it can be any logical entity within RLS or it may be separate logical entity outside the RLS. Similarly this invention proposes the mechanism to send single subscribe request to apply filtering rules to all watcher's subscriptions. This subscribe can be handled by Presence Server/RLS of any other logical entity. This logical entity could be part of Presence Server/ RLS of it could be a separate entity, a) System and Method for handling Watcher's Presence notification filtering rules in a resource list scenario using Resource List Server using SUBSCRIBE method This part of section deals with handling notificafion filtering based on Watcher's presence information. This method propose to have nofification blocking filter rules in the SUBSCRIBE request as mentioned in the above section 1 Detail Method. The Figure 2 shows basic proposal. In this Watcher W send SUBSCRIBE method and also include the notification blocking fitter rules (based on Watcher's Presence information). The RLS will subscribe to individual presentities as per Watcher request. Note RLS will also need presence information of Watcher W in order to apply notification blocking filter rules. For this RLS also subscribe to Presence information of Watcher W. So once RLS gets notification about the presence information of Watcher, RLS applies notification blocking filter rules on notifications of presence information of Presentities to the Watcher. The Structure of notification blocking filter rules and example schema is already discussed in the previous sections. This way notification blocking filter rules can be applied to the multiple Presentity using single subscribe request using RLS. i. Detail flow: Figure 3 shows, detail flow diagram for the proposed invention in case of multiple resource list case. The steps are as follows, 1. Watcher W sends the SUBSCRIBE request with filter body for presence based filtering. a, Request-URI set to resource list b. Notification blocking filter rules based on Watcher presence information {e.g. block notification when BUSY) 2. RLS validates the SUBSCRIBE request, and notification blocking filter rules if RLS doesn't support notification blocking filter rule then RLS may send error response or may neglect these rules and use subscribe normally (without notification rules) 3. RLS sends 200 OK response to Watcher W 4. RLS sends NOTIFY response to Watcher W with details of SUBSCRIPTION state a. If notification filters are not valid RLS can include the CondReject status in subscription state (to indicate the Watcher that conditions are rejected but subscription is valid) 5. RLS sut)scribes to presence information of Watcher W (for applying notification blocking filter rules) 6. RLS subscribes to Presentity A 7. RLS subscribes to Presentity B 8. PS of Watcher W sends 200 OK response to RLS 9. PS of Watcher W sends NOTIFY response to RLS to indicate the Watcher's presence information 10. PS of Presentity A sends 200 OK response to RLS 11. PS of Presentity A sends NOTIFY response to RLS to indicate his presence information 12. PS of Presentity B sends 200 OK response to RLS 13. PS of Presentity B sends NOTIFY response to RLS to indicate his presence information 14. Watcher W becomes BUSY, and wishes to block notifications and send PUBLISH to the PS 15. PS of Watcher sends 200 OK response to PUBLISH 16. PS of Watcher sends NOTIFY with state of Watcher as BUSY to RLS 17. Presentity A changes its state so PS of Presentity notify RLS 18. Presentity A changes its state so PS of Presentity notify RLS 19. Presentity B changes its state so PS of Presentity notify RLS 20. Presentity B changes its state so PS of Presentity notify RLS 21. RLS blocks all notifications till Watcher state is BUSY This way RLS blocks the unwanted notifications, which helps in reducing the radio resources and notification traffic, ii. RLS behaviour a. Extraction of Watcher's presence based notification blocking filter: The content type simple-filter-presfilter+xml for the Watcher's presence based notification blocking filter as proposed by the invention 1442/CHE/2006 "Watcher presence based notification control" will be used for setting filtering rules. When body of the SUBSCRIBE request contains above content type then RLS identifies the existence of the Watcher's presence related notification blocking filter. When identified, RLS extracts the notification blocking filter from the SUBSCRIBE body and stores it for further processing. b. Processing of the extracted Watcher's presence based notificafion blocking filter: RLS processes the extracted Watcher's presence based notification blocking filter as described in the invention 1442/CHE/2006 "Watcher presence based notification control" with following clarifications: If RLS understands and is able to handle these conditions as specified in the Watcher's presence related notification blocking filter, then RLS sends 200 OK response and the subsequent NOTIFY with subscription state header value as "active" and "CondOK" and the body with the requested presence attributes of the target resource list, RLS needs to SUBSCRIBE to the Watcher presence information in order to apply the notification blocking filter rules. So based on the condition set. RLS server will block the notifications coming from the Presentities. Upon this successful subscription with the Watcher's presence related notification blocking filter, the RLS stores the filtering rules to be applied for future generation of NOTIFY requests to Watcher. When generating the NOTIFY requests that contain the Presentity's presence attributes as requested by the Watcher, the RLS checks the conditions in the Watcher's presence based notification blocking filters. If the conditions match with the current Watcher's presence attributes as the RLS is aware of, then the RLS refrains from sending the NOTIFY requests to Watchers, otherwise, the RLS sends the NOTIFY requests to Watcher. If RLS identifies the Watcher's presence based notification blocking filters but it cannot evaluate the specified conditions in the filters then the RLS will send 200 OK or 202 Accepted response and the subsequent NOTIFY requests with subscription state header value as "terminated" and "CondReject", which tells the Watcher that the requested conditions in the Watcher's presence based notification blocking filter is not able to be evaluated, and then will terminate the subscription. Alternatively, if RLS wishes to maintain the subscription even if RLS does not understand the notification blocking filtering rules, then the RLS maintains the subscription by sending 200 OK or 202 Accepted response, and in the subsequent NOTIFY requests sets subscription state header value to "active" and "CondReject" while keeping the subscription. So when the Watcher receives the NOTIFY request with subschption state as "active" and "CondReject", then the client can recognize that the requested notification blocking filtehng rules are rejected or not understood by RLS but the requested subscription is still valid and thus can receive future notifications on the requested presence attributes of the target Present/ties, If RLS does not support the notification blocking filtering rules, then RLS will send the 403 Forbidden response or other appropriate error response to the SUBSCRIBE request. This may be depends on the local policy of the RLS. iii. Example for setting the notification rules in the SUSBCRIBE request for subscribing resource list This section gives the example for setting the Watcher's presence based notification blocking filter rules for resource list. When Watcher wants to subscribe to resource list, sends SUBSCRIBE request to RLS. If Watcher wants to set notification blocking rules based on the his presence information, then Watcher will embed the notification blocking rules in initial SUBSCRIBE request with content type as multipart, or if Watcher has already subscnbed to resource list then Watcher sends re-SUSBCRIBE request with content type as "application/simple-filter-presfilter+xmI" and include the notification blocking rules in the body. Table 1 shows the example SUSBCRIBE request with Watcher's presence based notification blocking filter ru\e. Here, the LIRI of the target resource list is "sip:[email protected]" and the URI of the requesting Watcher is "sip;[email protected]'. In this example, the notification blocking filter rule contain three conditions, which are: Condition 1) If the Watcher's RPID (RFC 4480 "RPID: Rich Presence Extensions to the Presence Information Data RLS Server depending the notification blocking filter rules and the procedure to handle the rules as explained in the previous subsection "ii) RLS Behaviour" sends the NOTIFY response to Watcher. The table 3 shows the exmaple notify response format NOTIFY sip: [email protected] SIP/2.0 Via: SIP/2.0/TCP RLserver.example.com SIP/2.0;branch=z9hG4bKna998sk From: ; tag=ffd2 To:;tag=ie4hbb8t Call-ID: [email protected] Event: presence Subscription-State: active;"CondOK" Max-Forwards: 70 CSeq: 8775 NOTIFY Contact: sip:RLserver.example.com Content-Type: ... Content-Length: ... Table 3: NOTIFY response from RLS Server The RLS also SUSBCRIBE to the Watcher presence information and get the presence information from the Watcher. The RLS applies the notification blocking filter rules based on the Watcher presence information. So this way notification blocking filter rules will be applied to the resource list presence subschption. b) System and Method for handling Watcher's Presence notification filtering rules in a resource list scenaho using Resource List Server using REFER method This section proposes to have REFER for setting the Watcher's presence based notification blocking filter rules for all RLS notifications. This part of section deals with handling such notification blocking filtering based on Watcher's presence information. This method propose to have notification blocking filter rules in the REFER request. The Figure 4 shows basic proposal. In this Watcher W send REFER method and also include the notification blocking filter rules (based on Watcher's Presence information). The RLS will subscribe to Watcher presence information in order to apply notification blocking filter rules. For this RLS also subscribe to Presence information of Watcher W. So once RLS gets notification about the presence information of Watcher, RLS applies notification blocking filter rules on notifications of presence information from all Presentities in the resource-list. This way notification blocking filter rules can be applied to the multiple Presentities using single REFER request. i. Detail flow: Figure 5 shows, detail flow diagram for the proposed invention in case of multiple resource list case. The steps are as follows: 1. Watcher W sends the SUBSCRIBE request with filter body for subscribing to resource list present in the RLS 2. RLS validates the SUBSCRIBE request, RLS sends 200 OK response to Watcher W 3. RLS sends NOTIFY response to Watcher W with details of SUBSCRIPTION state 4. RLS subscribes to Presentity A 5. RLS subscribes to Presentity B 6. PS of Presentity A sends 200 OK response to RLS 7. PS of Presentity A sends NOTIFY response to RLS to indicate his presence information 8. PS of Presentity B sends 200 OK response to RLS 9. PS of Presentity B sends NOTIFY response to RLS to indicate his presence information 10. Watcher wants to set notification blocking filter rules based on his presence information send the REFER request to RLS a. Request-URI set to RLS b. Refer-to: Reference to REFER body with Method is set to "SUBSCRIBE" c. Refer-sub: false d. BODY, Notification blocking filter rules 11. RLS sends 200 OK response to Watcher 12. RLS analyze the notification blocking filter rules and if RLS support this then store these filtering rules 13. RLS sends the notification to Watcher, 14. RLS subscribes to Watcher's presence information 15. Presence Sen/er of Watcher sends 200 OK response to subscription request 16. Presence Server of Watcher sends NOTIFY to subscription request for required presence information 17. Watcher sends PUBLISH with its state as BUSY to his Presence Server 18. PS of Watcher sends 200 OK response to PUBLISH 19. PS of Watcher sends NOTIFY with state of Watcher as BUSY to RLS 20. Presentity A changes its state so PS of Presentity notify RLS 21. Presentity A changes its state so PS of Presentity notify RLS 22. Presentity B changes its state so PS of Presentity notify RLS 23. RLS blocks all notifications m Watcher state is BUSY This way RLS blocks the unwanted notifications, which helps in reducing the radio resources and notification traffic. ii. RLS behaviour a. Extraction of Watcher's presence based notification blocking filter: The content type simple-filter-presfilter+xml for the Watcher's presence based notification blocking filter as proposed by the invenfion 1442/CHE/2006 "Watcher presence based nofificafion control" will be used for setting notification blocking filter rules. When body of the REFER request contains above content type then RLS identifies the existence of the Watcher's presence related notification blocking filter. When identified, RLS extracts the notification blocking filter from the body of the REFER request and stores it for further processing. b. Processing of the extracted Watcher's presence based notification blocking filter: RLS processes the extracted Watcher's presence based notification blocking filter as described in the invention 1442/CHE/2006 "Watcher presence based notification control" with following clarifications: If RLS understands and is able to handle these conditions as speci'^ed in the Watcher's presence related notification blocking filter, then RLS sends 200 OK response. RLS needs to SUBSCRIBE to the Watcher presence information in order to apply the notification blocking filter rules. Upon this successful subscription to the Watcher's presence information, the RLS starts to appiy the notification blocking filter rules to the generation of NOTIFY requests to Watcher. When generating the NOTIFY requests that contain the resource list's presence attributes as requested by the Watcher, the RLS checks the conditions in the Watcher's presence based notification blocking filters. If the conditions match with the current Watcher's presence attributes as the RLS is aware of, then the RLS refrains from sending the NOTIFY requests to Watchers, otherwise, the RLS sends the NOTIFY requests to Watcher. If RLS does not support the notification blocking filtering rules, then RLS will send the 403 Forbidden response or other appropriate error response to the REFER request. This may be depends on the local policy of the RLS. iii. Example flows for setting notification filtering rules using REFER method: This section gives the example for setting the notification blocking filter rules for resource list. When Watcher wants to subscribe to resource list, sends SUBSCRIBE request to RLS. If Watcher wants to set notification blocking filter rules based on the his presence information, then Watcher will send REFER request with content type as a simple-filter-presfilter+xml and Body will include the notification blocking filter rules. The table 4 shows the example REFER method structure. //dm:person/rpid:activities/rpid:away//dm:person/rpid:activities/rpid:meeting

Documents:

1193-CHE-2007 AMENDED CLAIMS 10-11-2014.pdf

1193-CHE-2007 FORM-13 10-11-2014.pdf

1193-CHE-2007 FORM-13 12-12-2013.pdf

1193-CHE-2007 POWER OF ATTORNEY 10-11-2014.pdf

1193-CHE-2007 EXAMINATION REPORT REPLY RECEIVED 10-11-2014.pdf

1193-che-2007 abstract.pdf

1193-CHE-2007 AMENDED CLAIMS 25-09-2014.pdf

1193-CHE-2007 AMENDED PAGES OF SPECIFICATION 25-09-2014.pdf

1193-che-2007 claims.pdf

1193-che-2007 correspondence-others.pdf

1193-che-2007 description (complete).pdf

1193-che-2007 drawings.pdf

1193-CHE-2007 EXAMINATION REPORT REPLY RECIEVED 25-09-2014.pdf

1193-CHE-2007 FORM-1 25-09-2014.pdf

1193-che-2007 form-1.pdf

1193-CHE-2007 FORM-13 17-12-2013.pdf

1193-che-2007 form-5.pdf

1193-CHE-2007 OTHER PATENT DOCUMENT 25-09-2014.pdf

1193-CHE-2007 POWER OF ATTORNEY 25-09-2014.pdf

1193-che-2007_correspondence-others.pdf

1193-che-2007_descreiption(provisional).pdf

1193-che-2007_drawings.pdf

1193-che-2007_form1.pdf

1193-che-2007_form26.pdf